bearophile wrote:
Double leading underscores are for temporary things, that will change and improve, like __traits.
> But this ctWriteln is meant to stay.
No it isn't. If we get bug 3702 ("magic namespace") approved, the name
of __ctfe and __ctfeWriteln will change. They are intentionally ugly
> Double leading underscores are for temporary things, that will change and
> improve, like __traits. But this ctWriteln is meant to stay. And the
> leading "ctfe" is redundant, so I suggest to call it ctWriteln, there is
> no need to give it an ugly name. It means "compile time write with
> newlin
Double leading underscores are for temporary things, that will change and
improve, like __traits. But this ctWriteln is meant to stay. And the leading
"ctfe" is redundant, so I suggest to call it ctWriteln, there is no need to
give it an ugly name. It means "compile time write with newline" inst
On Aug 9, 11 03:19, bearophile wrote:
KennyTM~:
I understand that you could implement `writeln` in terms of `write`, but
I question its practical value. Why do you need to print a tree at
compile time? pragma(msg) and __ctfeWriteln are mainly for debugging,
and adding a newline is very suita
KennyTM~:
> I understand that you could implement `writeln` in terms of `write`, but
> I question its practical value. Why do you need to print a tree at
> compile time? pragma(msg) and __ctfeWriteln are mainly for debugging,
> and adding a newline is very suitable (e.g. it won't mess up the
On Aug 8, 11 06:45, bearophile wrote:
KennyTM~:
__ctfeWrite is not complex, but I don't see the need for it.
I don't understand your point. Given __ctfeWrite you are able to create a
__ctfeWriteln but you can't do the opposite.
If I have to print something complex, like something tree-shape
KennyTM~:
> __ctfeWrite is not complex, but I don't see the need for it.
I don't understand your point. Given __ctfeWrite you are able to create a
__ctfeWriteln but you can't do the opposite.
If I have to print something complex, like something tree-shaped, and I have
just __ctfeWriteln, to cr
On 08.08.2011 1:38, KennyTM~ wrote:
Pull request: https://github.com/D-Programming-Language/dmd/pull/296
Previous discussion:
http://www.digitalmars.com/d/archives/digitalmars/D/CTFE_writeln_140241.html
This is the 2nd try to add a compile-time printing facility to D. The
previous pull reque
On Aug 8, 11 05:56, bearophile wrote:
KennyTM~:
So I go for my 2nd alternative, which is to add a magic function __ctfeWriteln
that does the same.
In my implementation, __ctfeWriteln will print the interpreted arguments
to stdmsg when CTFE-ed, and is a no-op in runtime (it can be configured
to
KennyTM~:
> So I go for my 2nd alternative, which is to add a magic function
> __ctfeWriteln
> that does the same.
>
> In my implementation, __ctfeWriteln will print the interpreted arguments
> to stdmsg when CTFE-ed, and is a no-op in runtime (it can be configured
> to throw an exception or
Pull request: https://github.com/D-Programming-Language/dmd/pull/296
Previous discussion:
http://www.digitalmars.com/d/archives/digitalmars/D/CTFE_writeln_140241.html
This is the 2nd try to add a compile-time printing facility to D. The
previous pull request uses std.stdio.writeln which cause
11 matches
Mail list logo
