On Monday, 10 August 2020 at 20:34:33 UTC, kinke wrote:
>> This does not work:
>
> This does and prints the desired output:
>
> class SharedArray(T)
> {
>   T[] array;
>   alias array this;
>
>   final @disable:
>   T front();
>   void popFront();
>   bool empty();
> }
>
> https://run.dlang.io/is/5ciCue

Thanks. I will accept this as the proper work-around.

On Monday, 10 August 2020 at 20:42:34 UTC, Steven Schveighoffer wrote:
> 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.

Sorry, I typed too quickly, I'm trying to say: by the __compiler__ -> by the std library.

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

Yes, it's the library did it wrong, I still hold the opinion that:

`writeln` should be a *view* (i.e read-only) function, it shouldn't *internally* call anything thing that change the data passed in.

On Monday, 10 August 2020 at 19:52:19 UTC, Steven Schveighoffer wrote:

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

compiler => library  :-)

BTW, where is the code of this interface testing sequence?

I think we should change the testing order to try slicing first, because slice is a “view” (readonly to the underlying data) struct.

On Monday, 10 August 2020 at 20:42:34 UTC, Steven Schveighoffer wrote:

> The fault here is Phobos for accepting classes as ranges (range classes are IMO an abomination that should never be used).
>
Honestly, I think that the real problem here is that alias this can be used with classes. I would argue that alias this should be available only for structs because:

1. There are no rules that define precedence: which should have priority alias this or one of the parents?
2. For classes you already have the inheritance mechanism and therefore alias this basically invites multiple inheritance into the problem (with its known issues: the diamond problem).

It would be easier for everyone if alias this would be banned and classes and just stick to structs.

Cheers,
RazvanN

On Monday, 10 August 2020 at 21:20:11 UTC, mw wrote:
> `writeln` should be a *view* (i.e read-only) function, it shouldn't *internally* call anything thing that change the data passed in.

So how should writeln deal with input ranges? Should it simply not be possible to print them, as that would (by their very nature) change them?

--
  Simen

On Monday, 10 August 2020 at 21:15:58 UTC, mw wrote:
> On Monday, 10 August 2020 at 20:34:33 UTC, kinke wrote:
>>> This does not work:
>>
>> This does and prints the desired output:
>>
>> class SharedArray(T)
>> {
>>   T[] array;
>>   alias array this;
>>
>>   final @disable:
>>   T front();
>>   void popFront();
>>   bool empty();
>> }
>>
>> https://run.dlang.io/is/5ciCue
>
> Thanks. I will accept this as the proper work-around.

There really shouldn't be a workaround, this just outlines that there's an ordering problem in writeln. It should be using front/popfront as a last resort if it isn't able to use another (better) method.

On Tuesday, 11 August 2020 at 13:36:19 UTC, Simen Kjærås wrote:
> So how should writeln deal with input ranges?

I would expect writeln to first try to use some const-interface (e.g. indexing if the given type provides that). Only if such interface is not available, it should try modifying interfaces like range pop-front.

On Monday, 10 August 2020 at 20:42:34 UTC, Steven Schveighoffer wrote:
> 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).

Yet, they allow to mask implementation of a range. Phobos shouldn't just prohibit all class based ranges, just those that don't implement right interfaces, such as InputRange(T) or ForwardRange(T).

On Monday, 10 August 2020 at 21:20:11 UTC, mw wrote:
> Yes, it's the library did it wrong, I still hold the opinion that:
>
> `writeln` should be a *view* (i.e read-only) function, it shouldn't *internally* call anything thing that change the data passed in.

This would disable writeln features people already use, you can create a simple const-flavored writeln wrapper:

void writeln(Args...)(in Args a)
{
    static import std.stdio;
    std.stdio.writeln(a);
}

int main(string[] args)
{
    Filenames a=new Filenames;
    writeln(a);
    return 0;
}