"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