I've just fixed UFCS for the experimental type function branch

[Meta]

On Thursday, 10 September 2020 at 18:05:23 UTC, Paul Backus wrote:
> On Thursday, 10 September 2020 at 17:05:02 UTC, Meta wrote:
>>
>> I'm curious, will this also work?
>>
>> size_t sizeOf(alias t)
>> {
>>     size_t result;
>>     /* static? */ if (__traits(isScalar))
>>     {
>>         static if (is(t == int))
>>             result += 32;
>>         else static if (...)
>>         ...
>>     }
>>     else static if (is(t == A[n], A, size_t n))
>>         result += A.sizeOf * n
>>     else static if (...)
>>         ...
>>     else
>>         /* static? */ foreach (field; t.tupleof)
>>             result += field.sizeOf
>>
>>     return result;
>> }
>>
>> Basically, is the implementation at a level where sizeOf can 
>> be turtles all the way down, with minimal or no reliance on 
>> __traits?
>
> One thing built-in .sizeof does that no user-code version can 
> do is "freeze" the size of a type to prevent additional members 
> from being added. For example, if you try to compile this code:
>
> struct S
> {
>     int a;
>     enum size = S.sizeof;
>     mixin("int b;");
> }
>
> ...you'll get an error:
>
> onlineapp.d-mixin-5(5): Error: variable onlineapp.S.b cannot be 
> further field because it will change the determined S size

It looks like it depends on the order of fields:

struct S
{
     int a;
     mixin("int b;"); //No error
     enum size = S.sizeof;
}

Ideally `enum size = S.sizeof` could be delayed until after all 
mixins are "evaluated" (is that during one of the semantic 
phases? I don't know much about how DMD actually works), but I 
imagine that would take some major re-architecting. Really 
though, is it even necessary to be able to "freeze" a type like 
this when evaluating type functions?