rather than punching a hole in const/immutable

struct S
meta {
int refCount;
....
}
do {
 int payload;
....
}

Immutable S s is now conceptually an immutable object and a mutable
object with metadata behind the scenes
that feels like a single object from a user perspective?

On 15/11/2021 10:28 PM, Danni Coy wrote:
> that feels like a single object from a user perspective?

The most important thing about this is: it'll all be in continuous memory.

Perfect for all of your crashing needs due to read only memory!

On Monday, 15 November 2021 at 09:28:41 UTC, Danni Coy wrote:
> rather than punching a hole in const/immutable
>
> struct S
> meta {
> int refCount;
> ....
> }
> do {
>  int payload;
> ....
> }
>
> Immutable S s is now conceptually an immutable object and a mutable
> object with metadata behind the scenes
> that feels like a single object from a user perspective?

That is functionally the same thing as '__mutable int refCount', discussed elsethread.

On Mon, Nov 15, 2021 at 9:50 PM Elronnd via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 15 November 2021 at 09:28:41 UTC, Danni Coy wrote:
> > rather than punching a hole in const/immutable
> >
> > struct S
> > meta {
> > int refCount;
> > ....
> > }
> > do {
> >  int payload;
> > ....
> > }
> >
> > Immutable S s is now conceptually an immutable object and a
> > mutable
> > object with metadata behind the scenes
> > that feels like a single object from a user perspective?
>
> That is functionally the same thing as '__mutable int refCount', discussed elsethread.

>From an implementation point of view maybe. It has the advantage of
having the linguistic model match what the compiler is doing behind the scenes (making it easier to reason about / conceptualise).

Would it be possible to limit operation of the writeable components to a small subset of the language which would allow the necessary operations but remove a lot of the complications?

On 15.11.21 11:36, rikki cattermole wrote:
> 
> On 15/11/2021 10:28 PM, Danni Coy wrote:
>> that feels like a single object from a user perspective?
> 
> The most important thing about this is: it'll all be in continuous memory.
> 
> Perfect for all of your crashing needs due to read only memory!

Whoever allocates the object knows the memory layout and can put it in writable memory.

On 15.11.21 08:05, Walter Bright wrote:
> On 11/14/2021 1:12 PM, Steven Schveighoffer wrote:
>> First, I'll note that `__mutable` on its own is perfectly sound.
> 
> I don't think so. It produces two kinds of immutability - one with mutable members, one with not. Different rules apply.
> 
> But then what do you do with opaque types? The compiler doesn't know which kind of immutable they are. So it is forced to go with the worst case - immutables are mutable. And it all falls apart.
> 

My answer to this was nondeterministic semantics. Just say what all the rewrites are that the compiler is allowed to do. Then @trusted __mutable functions have to ensure they function correctly _even if_ optimizations change the specific __mutable function calls and their arguments.

Another example of nondeterministic semantics is implicit moving. The compiler can either move directly or just copy construct and destroy. Then, the type itself has to ensure it does not matter for overall correctness which specific set of operations is applied even if they do not result in exactly the same bit patterns. This works and similar nondeterministic semantics can be made to work for __mutable data.

Of course, this is more technically involved than just saying "`immutable` means immutable" (a rare feat for D keywords), but you still have to address the issue of deallocation anyway.