"temporary" templates

Steven Schveighoffer schveiguy at gmail.com
Tue Nov 26 19:11:14 UTC 2019


On 11/26/19 1:59 PM, Paul Backus wrote:
> On Tuesday, 26 November 2019 at 18:45:35 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 26 November 2019 at 18:35:42 UTC, Stefan Koch wrote:
>>> In _general_ it's not possible to categorize a template  as being 
>>> temporary or  not.
>>> For language semantic reasons it is a requirement  for every 
>>> re-instantiated template to forward  to  exactly the same symbol as 
>>> was generated during the first instantiation.
>>
>> What if it kept *just* the symbol, but discarded its innards when 
>> under memory pressure, then could regenerate them if evaluated again?
> 
> This will cause compilation to become non-deterministic, since the 
> result of template evaluation can depend on the order in which 
> declarations are semantically analyzed:
> 
> enum hasFoo(T) = __traits(hasMember, T, "foo");
> 
> struct S {
>      // hasFoo!S is instantiated before the mixin is processed
>      static if (hasFoo!S) {}
>      mixin("int foo;");
> }
> 
> pragma(msg, hasFoo!S); // false
> 
> If for some reason the "innards" of `hasFoo!S` are discarded due to 
> memory pressure, reconstructing them later will give a different result.

But that's an evaluation order issue. hasFoo should be true in both 
cases. Otherwise, you have the paradox:

static assert(hasFoo!S == __traits(hasMember, T, "foo"))

Or we should essentially stop using templates to make __traits easier to 
write?

I ran into this recently as well:

https://issues.dlang.org/show_bug.cgi?id=20414

I do not agree that this is a "language" requirement for any good reason 
other than "that's how the compiler currently works."

-Steve


More information about the Digitalmars-d mailing list