November 15, 2021

On Monday, 15 November 2021 at 21:30:29 UTC, rikki cattermole wrote:

>

const and immutables are compiler guarantees, and we shouldn't be wanting the compiler to lie to us in our misunderstandings.

Hm, immutable, const, and pure are arbitrary symbols that means nothing more than what an updated language spec claim. Of course, one might argue that it is bad usability!

Also, you have to be in @trusted to change the setting of memory pages, and in @trusted you basically take upon yourself to uphold the spec (which involves a strong element of hubris given that few programmers know the full language semantics).

So that is basically the key issue. For @trusted to make sense, the type system has to be simple and intuitive.

So, I disagree, but I agree. :)

November 16, 2021
On 16/11/2021 10:38 AM, Ola Fosheim Grøstad wrote:
> On Monday, 15 November 2021 at 21:30:29 UTC, rikki cattermole wrote:
>> const and immutables are compiler guarantees, and we shouldn't be wanting the compiler to lie to us in our misunderstandings.
> 
> Hm, ```immutable```, ```const```, and ```pure``` are arbitrary symbols that means nothing more than what an updated language spec claim. Of course, one might argue that it is bad usability!
> 
> Also, you have to be in ```@trusted``` to change the setting of memory pages, and in ```@trusted``` you basically take upon yourself to uphold the spec (which involves a strong element of *hubris* given that few programmers know the full language semantics).
> 
> So that is basically the key issue. For ```@trusted``` to make sense, the type system has to be simple and intuitive.
> 
> So, I disagree, but I agree. :)

Oh yeah, all these guarantees go out the window for @system and @trusted code!

But at least you have to cast and do something naughty to do it, which is a good thing if it involves a potential crash.

What matters is that const/immutable won't let you do something naughty, without you actually proving that you want to do it.

So at least then @safe is still @safe ;)
November 15, 2021
On Monday, 15 November 2021 at 22:00:51 UTC, rikki cattermole wrote:
> Oh yeah, all these guarantees go out the window for @system and @trusted code!

If you only write @system then the semantics get easier!

That is… up-side-down in a way.
November 16, 2021
On Monday, 15 November 2021 at 21:30:29 UTC, rikki cattermole wrote:
> There is nothing stopping the compiler putting immutable values in ROM, nor the user who didn't know that something like __mutable is in use from making memory they allocated read only.
>

How will the compiler put something that is dynamically allocated in ROM?

November 16, 2021
On 16/11/2021 2:16 PM, deadalnix wrote:
> On Monday, 15 November 2021 at 21:30:29 UTC, rikki cattermole wrote:
>> There is nothing stopping the compiler putting immutable values in ROM, nor the user who didn't know that something like __mutable is in use from making memory they allocated read only.
>>
> 
> How will the compiler put something that is dynamically allocated in ROM?

It won't (or at least I'm not aware that there is a way to do it outside of globals/literals).

That particular situation would be for globals or literals.
November 16, 2021
On 16.11.21 02:33, rikki cattermole wrote:
> On 16/11/2021 2:16 PM, deadalnix wrote:
>> On Monday, 15 November 2021 at 21:30:29 UTC, rikki cattermole wrote:
>>> There is nothing stopping the compiler putting immutable values in ROM, nor the user who didn't know that something like __mutable is in use from making memory they allocated read only.
>>>
>>
>> How will the compiler put something that is dynamically allocated in ROM?
> 
> It won't (or at least I'm not aware that there is a way to do it outside of globals/literals).
> 
> That particular situation would be for globals or literals.

Again, the compiler is aware which memory ranges have __mutable fields in them and can just put those in the writable data segment. There is no opacity at that point. I think this is just a non-issue, you only pay for what you use.
November 16, 2021

On Monday, 15 November 2021 at 14:59:48 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 15 November 2021 at 12:58:46 UTC, Imperatorn wrote:

>

On Monday, 15 November 2021 at 09:42:03 UTC, Ola Fosheim Grøstad wrote:

>

So, I would think that could be covered by having a mechanism for inferring "full immutability"?

*offers you a cup of tea*

Thanks, I needed that ☕

November 16, 2021
On Monday, 15 November 2021 at 12:24:33 UTC, Timon Gehr wrote:
> 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.

Could be implemented by a pointer containing the address of the writable sub-struct. The address never changes so the pointer can reside in ROM.
November 16, 2021
On Tuesday, 16 November 2021 at 16:26:25 UTC, Patrick Schluter wrote:
> On Monday, 15 November 2021 at 12:24:33 UTC, Timon Gehr wrote:
>> 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.
>
> Could be implemented by a pointer containing the address of the writable sub-struct. The address never changes so the pointer can reside in ROM.

Exactly, similar to my proposal earlier. We simply have to add a way to opt-out of transitive const/immutability.

November 16, 2021
On 2021-11-15 20:16, deadalnix wrote:
> On Monday, 15 November 2021 at 21:30:29 UTC, rikki cattermole wrote:
>> There is nothing stopping the compiler putting immutable values in ROM, nor the user who didn't know that something like __mutable is in use from making memory they allocated read only.
>>
> 
> How will the compiler put something that is dynamically allocated in ROM?

At least in theory it could mark pages as read-only. Current compilers do that for statically-initialized constant data, but not for anything else.