how is this array subtyping inside struct (bug?) possible?

[Steven Schveighoffer]

On 8/10/20 4:13 PM, mw wrote:
>>> This defeats the purpose, i.e. the convenience that subtyping 
>>> mechanism supposed to provide.
>>
>> You are subtyping but inadvertently have turned a forward range 
>> (array) into an input range (iterate only once) by changing it into a 
>> class.
> 
> This subtyping loophole should be fixed by the compiler.

No, it is doing exactly what you asked it to do -- turn a non-reference 
type into a full reference type.

The fault here is Phobos for accepting classes as ranges (range classes 
are IMO an abomination that should never be used).

> 
> 
>> What might work (and I haven't tried this) is to @disable front, 
>> popFront, empty, and I think what will then happen is the compiler 
>> will try slicing instead (which should work) and iterate a copy of the 
>> array.
>>
>> e.g.:
>>
>> class SharedArray!T
>> {
>>    T[] array;
>>    alias array this;
>>
>>    @disable:
>>       front();
>>       popFront();
>>       empty();
>> }
> 
> This does not work:
> ```
>   Error: no identifier for declarator front()
>   Error: function declaration without return type. (Note that 
> constructors are always named this)
>   Error: no identifier for declarator popFront()
>   Error: function declaration without return type. (Note that 
> constructors are always named this)
>   Error: no identifier for declarator empty()
> ```
> 
> looks like `@disable` expect the full function implementation with body:

Ugh, no, I just forgot to put in the types:

@disable:
    T front();
    void popFront();
    bool empty();

And I figured I'd try it out rather than use you as a REPL ;)

They also need final to avoid putting the non-existent functions in the 
vtable.

This works (and prints what you want):

class SharedArray(T)
{
    T[] array;
    alias array this;

    @disable final:
       T front();
       void popFront();
       bool empty();
}

-Steve