Deprecating this(this)

[Nicholas Wilson]

On Monday, 2 April 2018 at 00:44:14 UTC, Jonathan M Davis wrote:
> On Monday, April 02, 2018 00:25:52 Nicholas Wilson via 
> Digitalmars-d wrote:
>> On Sunday, 1 April 2018 at 17:08:37 UTC, Andrei Alexandrescu 
>> wrote:
>> > On 4/1/18 10:59 AM, Nicholas Wilson wrote:
>> > [...]
>> > int[] sneaky;
>> > struct A
>> > {
>> >
>> >     private int[] innocent;
>> >     this(this)
>> >     {
>> >
>> >         sneaky = innocent;
>> >
>> >     }
>> >
>> > }
>> > void main()
>> > {
>> >
>> >     immutable a = A([1, 2, 3]);
>> >     auto b = a;
>> >     sneaky[1] = 42; // oops
>> >     import std.stdio;
>> >     writeln(a.innocent); // ooooops
>> >
>> > }
>> >
>> > Sadly this (and many similar ones) compiles and runs 
>> > warning-free on today's compiler. We really need to close 
>> > this loop, like, five years ago.
>>
>> How much of this class of bug would be eliminated by requiring 
>> that `this(this)` be pure for assignment to const and 
>> immutable objects? Arguably this(this) should always be pure 
>> in any sane program. The only reason I can think of is if 
>> you're trying to perf the number of copies you're making, but 
>> there is compiler help for that.
>
> All kinds of things could be done with a postlbit costructor 
> that don't actually involve copying. These include logging or 
> printing something, and they could include stuff like reference 
> counting, which may or may not need access to something 
> external. debug statements would solve some uses cases but not 
> all. Requiring that this(this) be pure has some of the same 
> issues that requiring opEquals to be pure or const or whatever 
> has. It makes sense in _most_ cases, but occasionally, there 
> are good reasons for it not to be - especially in a systems 
> language.

I wasn't suggesting this a global requirement of all this(this)s,
only to the _postblit assignment to const and immutable objects_ 
( where
being pure would to disallow the above bug). Note that this should
still be able to be worked around by cast()s (which are un at safe) 
and therefore require
@trusted to work in @safe code, in which case the programmer has 
presumably
thought about the situation and knows what he's doing.