Andrei Alexandrescu:

> Or would "static if (__ctfe)" work? -- Andrei

Currently it doesn't work, because __ctfe is a run-time variable. Walter originally tried and failed to make it a compile-time variable.

Bye,
bearophile

On Wed, 08 Oct 2014 13:10:11 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> Or would "static if (__ctfe)" work? -- Andrei
ha! The Famous Bug! it works, but not as people expected. as "static if" evaluates when function is *compiling*, __ctfe is false there, and so the whole "true" branch will be removed as dead code.

i believe that compiler should warn about this, 'cause i'm tend to repeatedly hit this funny thing.

On Wed, 8 Oct 2014 23:20:13 +0300
ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

p.s. or vice versa: "static if (__ctfe)" is always true, to non-ctfe code will be removed. sorry, i can't really remember what is true, but anyway, it works by removeing one of the branches altogether.

On Wednesday, 8 October 2014 at 20:15:51 UTC, Steven Schveighoffer wrote:
> On 10/8/14 4:10 PM, Andrei Alexandrescu wrote:
>> On 10/8/14, 1:01 PM, Andrei Alexandrescu wrote:
>
>>>
>>> That's a bummer. Can we get the compiler to remove the "if (__ctfe)"
>>> code after semantic checking?
>>
>> Or would "static if (__ctfe)" work? -- Andrei
>
> Please don't ask me to explain why, because I still don't know. But _ctfe is a normal runtime variable :) It has been explained to me before, why it has to be a runtime variable. I think Don knows the answer.

Well, the contents of the static if expression have to be evaluated at compile time, so static if (__ctfe) would always be true.

Also, if it were to somehow work as imagined then you'd have nonsensical things like this:

static if (__ctfe) class Wat {}
auto foo() {
  static if (__ctfe) return new Wat();
  return null;
}
static wat = foo();

wat now has a type at runtime that only exists at compile time.

On Wed, 8 Oct 2014 23:25:18 +0300
ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Wed, 8 Oct 2014 23:20:13 +0300
> ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> p.s. or vice versa: "static if (__ctfe)" is always true, to non-ctfe code will be removed. sorry, i can't really remember what is true, but anyway, it works by removeing one of the branches altogether.
hm. i need some sleep. or new keyboard. or both.

On 10/08/2014 10:25 PM, ketmar via Digitalmars-d wrote:
> On Wed, 8 Oct 2014 23:20:13 +0300
> ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> p.s. or vice versa: "static if (__ctfe)" is always true, to non-ctfe
> code will be removed. sorry, i can't really remember what is true, but
> anyway, it works by removeing one of the branches altogether.
>

This is probably a regression somewhere after 2.060, because with 2.060 I get

Error: variable __ctfe cannot be read at compile time
Error: expression __ctfe is not constant or does not evaluate to a bool

as I'd expect.

On Wed, 08 Oct 2014 23:40:01 +0200
Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> This is probably a regression somewhere after 2.060, because with 2.060 I get
> 
> Error: variable __ctfe cannot be read at compile time
> Error: expression __ctfe is not constant or does not evaluate to a
> bool
> 
> as I'd expect.
i remember now that i was copypasting toHash() from druntime some time
ago and changed "if (__ctfe)" to "static if (__ctfe)" in process. it
compiles and works fine, and i don't even noticed what i did until i
tried to change non-ctfe part of toHash() and found that my changes had
no effect at all. and then i discovered that "static".

this was 2.066 or 2.067-git.

and now i can clearly say that "static if (__ctfe)" leaving only ctfe
part.

that was somewhat confusing, as i was pretty sure that "if (__ctfe)"
*must* be used with "static".

Am Wed, 08 Oct 2014 13:01:43 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 10/8/14, 1:13 AM, Johannes Pfau wrote:
> >
> > Code in if(__ctfe) blocks could be (and should be) allowed:
> > https://github.com/D-Programming-Language/dmd/pull/3572
> >
> > But if you have got a normal function (string generateMixin()) the compiler can't really know that it's only used at compile time. And if it's not a template the code using the GC will be compiled, even if it's never called. This might be enough to get undefined symbol errors if you don't have an GC, so the error messages are kinda valid.
> 
> That's a bummer. Can we get the compiler to remove the "if (__ctfe)" code after semantic checking?
> 
> Andrei

I think you misunderstood, code in if(__ctfe) is already removed, it
never gets into the binary. But the @nogc/-vgc checks still complain
about GC allocations in if(__ctfe). This is easy to fix, but as ctfe is
a runtime variable you could also do (if(__ctfe || dice() == 1 )) and
the decision about complex cases stopped pull #3572.

What I meant is that the compiler can't know that this code is CTFE-only and -vgc must complain:

string generateMixin(string a)
{return "int " ~ a ~ ";";}
mixin(generateMixin());

But there are workarounds:
http://dpaste.dzfl.pl/e689585c0a95
(Note that dead-code elimination should be able to remove all functions
marked as private)

Am Tue, 07 Oct 2014 15:57:58 +0000
schrieb "Dmitry Olshansky" <dmitry.olsh@gmail.com>:

> I made a proposal to quantatively measure and tabulate all GC allocations in Phobos before coming up with solutions to "@nogc Phobos".
> 
> After approving node from Andrei I've come up with a piece of automation to extract this data and post it on wiki.
> 
> So here is the exhustive list of everything calling into GC in Phobos (-vgc compiler flag):
> 
> http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage
> 
> Including source links, a wild guess at function's name and the compiler's warning message for potential GC call.
> 
> As far as data goes this is about as good as we can get, the next phase is labeling this stuff with potential solution(s). Again doing all by hand is tedious and hardly useful.
> 
> Instead we need to observe patterns and label it automatically until the non-trivial subset remains. So everybody, please take time and identify simple patterns and post back your ideas on solution(s).
> 
> So far I see the most frequent cases:
> - `new SomeException` - switch to RC exceptions
> - AA access - ??? (use user-defined AA type as parameter?)
> - array concat - ???
> - closure - ???
> 
> 
> 
> ---
> Dmitry Olshansky

Another observation: idup/dup are not reported by -vgc (This is correct
behavior. @nogc detects these as normal functions without @nogc
attribute and complains. -vgc does not report calls to non-@nogc
functions).
However, idup/dup might be common and it might make sense to grep for
them manually?

Am Wed, 8 Oct 2014 23:20:13 +0300
schrieb ketmar via Digitalmars-d <digitalmars-d@puremagic.com>:

> On Wed, 08 Oct 2014 13:10:11 -0700
> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
> 
> > Or would "static if (__ctfe)" work? -- Andrei
> ha! The Famous Bug! it works, but not as people expected. as "static if" evaluates when function is *compiling*, __ctfe is false there, and so the whole "true" branch will be removed as dead code.
> 
> i believe that compiler should warn about this, 'cause i'm tend to repeatedly hit this funny thing.

Lol, definitely! I made that mistake myself and Robert Schadek, too in his std.logger. It is now the #1 bug in D code.

-- 
Marco