DIP 1018--The Copy Constructor--Final Review

Paolo Invernizzi paolo.invernizzi at gmail.com
Mon Mar 4 12:59:36 UTC 2019


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


More information about the Digitalmars-d mailing list