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

[mw]

>> 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.


> 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:

https://dlang.org/spec/attribute.html#disable


BTW, this way of (thinking) fixing the problem is one step closer 
to Eiffel's mechanism: i.e. member level tailored inheritance.

Sigh, this is not done earlier into the language.