how is this array subtyping inside struct (bug?) possible?
Steven Schveighoffer
schveiguy at gmail.com
Mon Aug 10 20:42:34 UTC 2020
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
More information about the Digitalmars-d
mailing list