On Sunday, 3 March 2019 at 21:33:07 UTC, Paolo Invernizzi wrote:
> On Sunday, 3 March 2019 at 13:06:31 UTC, Nick Treleaven wrote:
>> Andrei has updated the DIP explaining why this wouldn't be a good @safe solution - see the `class Window` example:
>>
>> https://github.com/dlang/DIPs/blob/5a10e274f7befcd2e615cdcbee549791cf11318e/DIPs/accepted/DIP1018.md#breaking-changes-and-deprecations
>
> __mutable

You mean annotate all reference type fields with __mutable? I really don't think that is what it is being designed for. Razvan's proposal [1] has many restrictions on __mutable:

* "__mutable can only be applied to private members"
* "Global/Local and static variables cannot be __mutable"
* "__mutable data can only be manipulated in @system code"
* "__mutable fields of const instances also need to be regarded as shared" [*]

These restrictions mean mass __mutable use on reference type fields would be unsafe and very prone to introducing races in MT code.

[1] https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md
[*] Note: I submitted a PR to fix some typos in this section

On Monday, 4 March 2019 at 11:20:22 UTC, Nick Treleaven wrote:
> On Sunday, 3 March 2019 at 21:33:07 UTC, Paolo Invernizzi wrote:
>> On Sunday, 3 March 2019 at 13:06:31 UTC, Nick Treleaven wrote:
>>> Andrei has updated the DIP explaining why this wouldn't be a good @safe solution - see the `class Window` example:
>>>
>>> https://github.com/dlang/DIPs/blob/5a10e274f7befcd2e615cdcbee549791cf11318e/DIPs/accepted/DIP1018.md#breaking-changes-and-deprecations
>>
>> __mutable
>
> You mean annotate all reference type fields with __mutable? I really don't think that is what it is being designed for. Razvan's proposal [1] has many restrictions on __mutable:
>
> * "__mutable can only be applied to private members"
> * "Global/Local and static variables cannot be __mutable"
> * "__mutable data can only be manipulated in @system code"
> * "__mutable fields of const instances also need to be regarded as shared" [*]
>
> These restrictions mean mass __mutable use on reference type fields would be unsafe and very prone to introducing races in MT code.
>
> [1] https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md
> [*] Note: I submitted a PR to fix some typos in this section

I mean that we have transitioned from struct memcpy + postblit to copyctor, but both solutions are sub-optimal.

Citing Andrei addition, "so forcing const on the copy constructor's right-hand side would make simple copying task UNDULY difficult", that I interpret as lack of plasticity in the language in expressing such use case.

There's the need to keep the original type of the value passed to the parameters as it is, and to express that the argument can't be muted in the method, BUT indirection can be taken.

I've the impression that the road of dealing with such problem first, and then dissecting postblit + mutable (not necessarily in the current Razvan DIP design) would have resulted in a better way to solve what we are currently trying to solve now.

Well, but that's bike shedding, so... just don't take my word too seriously...

:-P

- P

On Monday, 4 March 2019 at 12:59:36 UTC, Paolo Invernizzi wrote:
> Citing Andrei addition, "so forcing const on the copy constructor's right-hand side would make simple copying task UNDULY difficult", that I interpret as lack of plasticity in the language in expressing such use case.
>
> There's the need to keep the original type of the value passed to the parameters as it is, and to express that the argument can't be muted in the method, BUT indirection can be taken.

That can be done with inout:

struct A
{
    int[] a;
    this(ref inout int[] b) inout
    {
        a=b;
    }
}

void f()
{
    int[] b;
    A a=A(b); //mutable ok
    const A a1=const A(b); //const ok
}

On 3/2/19 7:55 AM, Atila Neves wrote:
> On Friday, 1 March 2019 at 13:59:41 UTC, Olivier FAURE wrote:
>> On Thursday, 28 February 2019 at 10:44:36 UTC, Mike Parker wrote:
>>> [...]
>>
>> So, the big point of contention seems to be the possibility that structs have copy constructors taking non-const arguments.
>>
>> [...]
> 
> The copy constructor doesn't *have* to take a ref to mutable. It can be ref const(T). It just doesn't force it.

Correctamundo. (Also the case in C++.)