head const (again), but for free?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Mon Jan 11 20:07:48 UTC 2021


On Monday, 11 January 2021 at 19:05:13 UTC, Q. Schroll wrote:
> Your readonly is near useless if you really want it to mean 
> "head immutable" and not "head const". The value immutable 
> provides is due to being transitive. "Head immutable" is 
> unnecessary restrictive and has low guarantees.
> For example, a head_immutable(int*)* cannot bind a int** 
> variable, because immutable and mutable are referentially 
> incompatible; head_const(int*)* can bind int** the same way 
> const(int*)* can.

So, I disagree strongly with this. Head immutable is basically 
the default mutability of tuples in most languages. It is used a 
lot.

Const is too weak for the optimizer to make good use of. I 
basically never want transitive immutable. The only exception 
would be a lookup-table, but I have no problem modelling that 
manually...


> For that, I'd suggest `final` as the name. It's already a 
> keyword and that's what it means on the first level.

No, final is semantically different. I understand what you mean, 
but mixing concepts like that is no good it makes a language more 
hard to read.

"readonly" is pretty standard with a very clear and concise 
meaning. E.g. if you put a pointer in read-only-memory then that 
means you cannot change the pointer, it does not mean that what 
is pointed to cannot be changed.

So "readonly" would be far more useful than immutable currently 
is, as it can modell anything immutable can.

This also means you can make much more immutable than today which 
may have optimization benefits.


> If you go with that DIP, it will probably be rejected because 
> final would have to be implemented and maintained, while its 
> application is very limited. There's probably a reason D went 
> from D1 to D2 trading head const for transitive const.

Transitive const is a mistake. Transitive immutable is useful for 
lookup-structures, but that makes it very limited and also 
prevents extending such structures with caching mechanisms.

The fact that immutable cannot even model read-only-memory (ROM), 
which is very useful in system level programming, is a sign that 
it is inadequate.





More information about the Digitalmars-d mailing list