Deprecating this(this)

[Steven Schveighoffer]

On 4/2/18 10:24 AM, Nicholas Wilson wrote:
> On Monday, 2 April 2018 at 14:07:21 UTC, Steven Schveighoffer wrote:
>> On 4/1/18 10:34 AM, ag0aep6g wrote:
>>> On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote:
>>>> One issue is that postblit constructors fundamentally don't work 
>>>> with const. The problem is that a postblit constructor works by 
>>>> copying the object and _then_ mutating it, and you can't mutate a 
>>>> const object.
>>>
>>> I'm not so sure if that's fundamental. Can't we just say that the 
>>> copy is head-mutable at the time when the postblit function is 
>>> called, and it only becomes fully const after that?
>>>
>>> The destination can't be const/immutable already, or you wouldn't be 
>>> able to write there anyway.
>>
>> Yes, precisely what I had been arguing here: 
>> https://issues.dlang.org/show_bug.cgi?id=18417#c5, however 
>> const/immutable postblit was recently deprecated by: 
>> https://github.com/dlang/dmd/pull/8032
>>
>> So I don't think D is going to allow const postblit any more. Maybe 
>> not even postblit any more.
>>
> 
> Andrei did post an example where treating the designation as mutable, 
> stuffing references to mutable data into is and then treating it as 
> immutable leaves you with an immutable reference to immutable data.

I think you meant immutable reference to mutable data.

> 
> However i think that loophole is fixed if you only allow assignment to 
> const/immutable from a pure postblit.
> 

It's pretty straightforward I would think: If a postblit is being called 
on an immutable, it *must* be new data, because if it was data that just 
got overwritten, that data couldn't possibly be immutable. Therefore, 
there's leeway to mutate the head at that point, because nothing else 
can see it yet. Doesn't need to be pure.

Same leeway as an immutable constructor I think.

But all this discussion is moot if the postblit is going away.

-Steve