Walter looked at http://erdani.com/conversions.svg and said actually "const inout" and "const inout shared" should not exist as distinct qualifier groups, leading to the simplified qualifier hierarcy in http://erdani.com/conversions-simplified.svg.

Are we missing something? Is there a need for combining const and inout?


Thanks,

Andrei

On Saturday, 1 July 2017 at 21:47:20 UTC, Andrei Alexandrescu wrote:
> Walter looked at http://erdani.com/conversions.svg and said actually "const inout" and "const inout shared" should not exist as distinct qualifier groups, leading to the simplified qualifier hierarcy in http://erdani.com/conversions-simplified.svg.
>
> Are we missing something? Is there a need for combining const and inout?
>
>
> Thanks,
>
> Andrei

inout is bascially the same as const for all parctical purposes.

On 01.07.2017 23:47, Andrei Alexandrescu wrote:
> Walter looked at http://erdani.com/conversions.svg and said actually "const inout" and "const inout shared" should not exist as distinct qualifier groups, leading to the simplified qualifier hierarcy in http://erdani.com/conversions-simplified.svg.
> 
> Are we missing something?

I don't think so.

> Is there a need for combining const and inout?
> ...

In DMD's implementation, yes. (Combinations of qualifiers are represented as integers instead of nested AST nodes.)

const(const(T))     = const(T)
const(immutable(T)) = immutable(T)
const(inout(T))     = ?

It used to be the case that const(inout(T)) = const(T), but this is wrong, because if we replace 'inout' by 'immutable', the result should be immutable(T), not const(T). Hence const(inout(T)) cannot be reduced further.

The simplified hierarchy is enough though. The more complex one can be derived from it. Since S -> const(S) for all S, it directly follows that inout(T) -> const(inout(T)) for all T (we can choose S=inout(T)).

On 02.07.2017 00:10, Stefan Koch wrote:
> On Saturday, 1 July 2017 at 21:47:20 UTC, Andrei Alexandrescu wrote:
>> Walter looked at http://erdani.com/conversions.svg and said actually "const inout" and "const inout shared" should not exist as distinct qualifier groups, leading to the simplified qualifier hierarcy in http://erdani.com/conversions-simplified.svg.
>>
>> Are we missing something? Is there a need for combining const and inout?
>>
>>
>> Thanks,
>>
>> Andrei
> 
> inout is bascially the same as const for all parctical purposes.

struct S{
    int x;
    ref inout(int) foo()inout{
        return x;
    }
}

void main(){
    S s;
    s.foo()++; // ok!
    const(S) t = s;
    import std.stdio;
    writeln(t.foo());
    // t.foo()++; // error
}

On Saturday, 1 July 2017 at 22:16:12 UTC, Timon Gehr wrote:
>
> struct S{
>     int x;
>     ref inout(int) foo()inout{
>         return x;
>     }
> }
>
> void main(){
>     S s;
>     s.foo()++; // ok!
>     const(S) t = s;
>     import std.stdio;
>     writeln(t.foo());
>     // t.foo()++; // error
> }

Oh damn. I was not aware that it could behave non-constly.
since when does it do that ?

On 07/01/2017 02:47 PM, Andrei Alexandrescu wrote:
> the simplified qualifier hierarcy in
> http://erdani.com/conversions-simplified.svg.

Can't we simplify it by cutting it in half and adding that immutable is implicitly shared?

1) unqualified -> const
2) inout -> const
3) immutable -> const

4) shared is implicit only for immutable

> Is there a need for combining const and inout?

I think there is a reason but only one person knows. :)

Ali

On 07/01/2017 06:12 PM, Timon Gehr wrote:
> On 01.07.2017 23:47, Andrei Alexandrescu wrote:
>> Walter looked at http://erdani.com/conversions.svg and said actually "const inout" and "const inout shared" should not exist as distinct qualifier groups, leading to the simplified qualifier hierarcy in http://erdani.com/conversions-simplified.svg.
>>
>> Are we missing something?
> 
> I don't think so.
> 
>> Is there a need for combining const and inout?
>> ...
> 
> In DMD's implementation, yes. (Combinations of qualifiers are represented as integers instead of nested AST nodes.)
> 
> const(const(T))     = const(T)
> const(immutable(T)) = immutable(T)
> const(inout(T))     = ?
> 
> It used to be the case that const(inout(T)) = const(T), but this is wrong, because if we replace 'inout' by 'immutable', the result should be immutable(T), not const(T). Hence const(inout(T)) cannot be reduced further.
> 
> The simplified hierarchy is enough though. The more complex one can be derived from it. Since S -> const(S) for all S, it directly follows that inout(T) -> const(inout(T)) for all T (we can choose S=inout(T)).

Thanks! Well I do want to have a hierarchy with all possible qualifier combinations for utmost clarity. Only the combinations listed are valid, e.g. there's no "immutable inout" or whatever.

Vaguely related question: should "const" convert implicitly to "const shared"? The intuition is that the latter offers even less guarantees than the former so it's the more general type. See http://erdani.com/conversions3.svg.

That would be nice because we have "const shared" as the unique root of the qualifier hierarchy.


Andrei

On 07/01/2017 11:47 PM, Andrei Alexandrescu wrote:
> Walter looked at http://erdani.com/conversions.svg and said actually "const inout" and "const inout shared" should not exist as distinct qualifier groups, leading to the simplified qualifier hierarcy in http://erdani.com/conversions-simplified.svg.

This may be a stupid question, but those graphs say: inout -> const, but inout may stand for shared and there's no shared -> const.

How can inout -> const be allowed while shared -> const is forbidden?

On 02.07.2017 00:26, Stefan Koch wrote:
> On Saturday, 1 July 2017 at 22:16:12 UTC, Timon Gehr wrote:
>>
>> struct S{
>>     int x;
>>     ref inout(int) foo()inout{
>>         return x;
>>     }
>> }
>>
>> void main(){
>>     S s;
>>     s.foo()++; // ok!
>>     const(S) t = s;
>>     import std.stdio;
>>     writeln(t.foo());
>>     // t.foo()++; // error
>> }
> 
> Oh damn. I was not aware that it could behave non-constly.
> since when does it do that ?

Since the beginning. :)

The point of inout is in essence to allow writing an identity function that can operate on data of any mutability qualifier with support for virtual calls and without duplicating code in the binary.

On 02.07.2017 01:08, Andrei Alexandrescu wrote:
> 
> Thanks! Well I do want to have a hierarchy with all possible qualifier combinations for utmost clarity. Only the combinations listed are valid, e.g. there's no "immutable inout" or whatever.
> ...

immutable(inout(T)) is valid syntax, but this type is equal to immutable(T).

> Vaguely related question: should "const" convert implicitly to "const shared"? The intuition is that the latter offers even less guarantees than the former so it's the more general type. See http://erdani.com/conversions3.svg.
> 
> That would be nice because we have "const shared" as the unique root of the qualifier hierarchy.

This means that there can be aliasing between an unqualified reference and a const shared reference. Therefore, you can have code that mutates unshared data while another thread is reading it.

What should the semantics of this be?

The only potential issue is that it could restrict code operating on unshared data because it needs to play nice in some way to allow consistent data to be read by another thread.