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

[Avrina]

On Monday, 10 August 2020 at 12:03:06 UTC, Paul Backus wrote:
> On Monday, 10 August 2020 at 02:50:20 UTC, mw wrote:
>> On Monday, 10 August 2020 at 02:38:55 UTC, RazvanN wrote:
>>> On Sunday, 9 August 2020 at 21:12:58 UTC, mw wrote:
>>>
>>>> I'm *directly* access the underlying array, so why its 
>>>> length changed to 0 after writeln?
>>>>
>>> You are accessing the underlying array after it was consumed. 
>>> The line writeln(s0.fns) passes class, if you want to pass 
>>> the underlying array you should type `writeln(so.fns.array)` 
>>> and then it will not consume the array.
>>
>> I know that; and that's exactly I call it a subtyping bug: 
>> i.e. directly access & access via subtyping behave differently:
>
> You are subtyping a value type (array) with a reference type 
> (class). So when you directly access it, it's passed by value, 
> but when you pass the subtype, it's passed by reference.
>
> In other words, using `alias this` does not create a *true* 
> subtype (according to the Liskov substitution principle), 
> because it allows you to change the way the type is copied from 
> by-value to by-reference.

This really doesn't excuse why this bug is happening. Why is 
writeln() using front() and popFront() that modifies the range 
rather than simply using foreach()? Why is it modifying something 
it knows to be a class? This is definitely a bug that should be 
fixed. Not sure why people are trying to explain it away, looking 
that the writeln implementation it is completely convoluted. It's 
no wonder bugs like this are going to happen.