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
