On Wednesday, 13 January 2021 at 19:22:07 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 13 January 2021 at 18:37:02 UTC, sighoya wrote:
>> Yep, head const is usually readonly or better final, readonly should be transitive.
>
> Why? "immutable" is transitive in D. readonly memory or registers are not transitive.

The difference is readonly memory didn't know about the type of data saved in them. A pointer or raw data is in the end the same thing, just bytes.

Immutable var in high level languages denote a value even if this value consists of pointers.
Most languages simply don't follow the model.

> No, readonly in technical specifications usually means that it is isn't possible to write to it at all. e.g. readonly hardware registers. They can still point to writable memory.

Usually, readonly is only a view of a variable, not a part of type, so you can't change the value of a readonly variable though the value can be changed from outside.
So we still have a variable whereas for immutable we have what we call a value.


> "readonly" in Typescript and C# is immutable, not const.

But what happens if I initialize a readonly variable with an object which I mutate from the outside afterwards?
This shouldn't be possible with immutable because of being globally unchangeable.
In D you can only pass immutable parts into the initialization of an immutable aggregate to prohibit any side effect.
But is this the same behavior with readonly in Typescript, I don't think so.

The proposed readonly in C# would be likewise non immutable as shown from https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/readonly:

>Because reference types contain a reference to their data, a field that is a readonly reference type must always refer to the same object. That object isn't immutable.


> Which languages are you thinking of?

C#, Typescript, Rust, Swift.

I think what D offers with immutable is unique, I can't even count other languages with my fingers providing the same feature except pure languages.

On Wednesday, 13 January 2021 at 19:42:14 UTC, Meta wrote:
> I can see the value in head-immutable, in terms of type system guarantees, but not head-const.

I think they are both worthwhile and if we provide one of them we should also provide the other combinations. They are already mentioned in the D documentation with comparison to C++.

One point for head const aka "final" would be to align to C#/Java though a weak one.

On Wednesday, 13 January 2021 at 19:42:14 UTC, Meta wrote:
> Is there even any value to having head-const in a language? As I think Walter has said before, it's basically just documentation/convention in C++. I can see the value in head-immutable, in terms of type system guarantees, but not head-const.

Well, yes, but in the case of C++ there are no guarantees, so it is for catching bugs, parametric typing and overloading. I don't think it brings optimization benefits?

In the case of head-immutable it allows caching of calculations across FFI calls and assembly code for instance. With transitive immutable much less data can be protected.

On Wednesday, 13 January 2021 at 19:42:14 UTC, Meta wrote:
> [snip]
>
> Is there even any value to having head-const in a language? As I think Walter has said before, it's basically just documentation/convention in C++. I can see the value in head-immutable, in terms of type system guarantees, but not head-const.

I don't really understand the difference between head-const and head-immutable.

On Wednesday, 13 January 2021 at 19:52:16 UTC, sighoya wrote:
> Immutable var in high level languages denote a value even if this value consists of pointers.
> Most languages simply don't follow the model.

Not sure what you mean? In functional languages _everything_ is immutable. In imperative languages immutable tend to be only one level, not transitive?


> Usually, readonly is only a view of a variable, not a part of type, so you can't change the value of a readonly variable though the value can be changed from outside.

No, that would be "const", "readonly" does not allow changes after initialization.


> But what happens if I initialize a readonly variable with an object which I mutate from the outside afterwards?

No problem.

But you cannot make the "var" point to a different object. It is locked to be a pointer to that memory address throughout the entire lifespan.


> In D you can only pass immutable parts into the initialization of an immutable aggregate to prohibit any side effect.
> But is this the same behavior with readonly in Typescript, I don't think so.

Not sure what you mean. "immutable" is transitive, so it is only allowed to point to "immutable". This is what "readonly" is supposed to relax. That is the whole point! :-)


>
> The proposed readonly in C# would be likewise non immutable as shown from https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/readonly:
>
>>Because reference types contain a reference to their data, a field that is a readonly reference type must always refer to the same object. That object isn't immutable.

This means that the pointer is immutable, but the pointed-to object is not immutable.

Same as the "readonly" that I propose as an addition to "immutable" for D.

On Wednesday, 13 January 2021 at 20:21:33 UTC, jmh530 wrote:
> I don't really understand the difference between head-const and head-immutable.

Const allows the content to change through another reference.

Immutable does not.


So you can have one pointer that reference an object in "const mode", and another pointer that reference the same object in "mutable mode".

With immutable all pointers will reference the object in "immutable mode", so you can reuse any calculations you have derived from immutable objects with no fear of it becoming outdated.

However, with head-immutable the object is allowed to reference stuff that can be modified.

So, you could have an immutable meta-data-object that reference a writable-file-object. Then the meta-data-object could never change, so you can be certain that whatever you derive from it is always current.

On Wednesday, 13 January 2021 at 20:21:33 UTC, jmh530 wrote:
> On Wednesday, 13 January 2021 at 19:42:14 UTC, Meta wrote:
>> [snip]
>>
>> Is there even any value to having head-const in a language? As I think Walter has said before, it's basically just documentation/convention in C++. I can see the value in head-immutable, in terms of type system guarantees, but not head-const.
>
> I don't really understand the difference between head-const and head-immutable.

Do you understand the difference between const and immutable (the transitive ones)?
For declaring an int, it's almost the same.

const int i = 0;
immutable int j = 0;

You cannot write i and j regardless which one you use. Only &i and &j will be typed differently, and that's where the difference begins.

int i = 0;
const(int)* p = &i; // okay
immutable(int)* q = &i; // error

But because there are no indirections in an int, for p and q it would be the same if const and immutable weren't transitive. Enter double pointers:

int i = 0;
int* p = &i;
immutable(int*)* qq = &p; // error, **qq could change through i and *p.
const(int*)* pp = &p; // okay, const only means no write through this

Here, it makes a difference that const and immutable are transitive.

int i = 0;
head_immutable(int*) p = &i; // okay, immutable ptr to mutable value
head_const(int*)* pp = &p; // okay, too
int* q = &i;
head_immutable(int*)* qq = &p; // error, *qq could change through q.

Head immutable is more restrictive than head const, obviously.

On Wednesday, 13 January 2021 at 22:15:59 UTC, Q. Schroll wrote:
> [snip]
>
> int* q = &i;
> head_immutable(int*)* qq = &p; // error, *qq could change through q.
>
> Head immutable is more restrictive than head const, obviously.

Should that last head_immutable be &q instead of &p?

I liked Ola's description, but this one works through the basics in a way that really helps. So thanks.

On Wednesday, 13 January 2021 at 22:34:04 UTC, jmh530 wrote:
> On Wednesday, 13 January 2021 at 22:15:59 UTC, Q. Schroll wrote:
>> [snip]
>>
>> int* q = &i;
>> head_immutable(int*)* qq = &p; // error, *qq could change through q.
>>
>> Head immutable is more restrictive than head const, obviously.
>
> Should that last head_immutable be &q instead of &p?

Yes.