tail const

[spir]

On Tue, 30 Nov 2010 23:57:04 +0100
Fawzi Mohamed <fawzi at gmx.ch> wrote:

> Speaking about D mistakes Steve spoke about missing tail const.
> I was thinking about this, and I fully agree that it is a hole.
> I don't know if it was already discussed, but I was thinking that one  
> could introduce
> 	*const T t1;
> and
> 	*immutable T t2;
> with the following meaning:
> const or immutable is applied on the "dereferenced" type. For classes  
> this would mean the object, not the pointer.
> Thus for example if T is a class type one would be able to reassign t1
> 	t1=t2;
> but not to modify the content of t1 or t2 in any way.
> One can also extend it to array types: if T is U[], then it would mean  
> const(U)[] or immutable(U)[], and to pointer types,
> *const int* would then mean const(int)*.
> For other types maybe the best solution would be to
> 	drop the const/immutable for basic types, functions and delegates
> 	apply it to all fields of a struct (not sure how much work this would  
> be to implement)
> 
> This use of * should not introduce much ambiguity (a pointer is T*,  
> indeed also const*T would be almost as unambiguos).

It seems, as Andrei pointed (!) a few days ago, that the issue is purely syntactic. Namely, since class instance de/referencing is completely implicit _including_ in class definition and variable declaration, there is no way to denote constness on the pointer's target. As you show, we do not need any new lexical or syntactic artifact for arrays or explictely pointed thingies.
This is in contrast with languages in which class instance dereferencing is implicit, to access slots:
	o.someAspect = 1
	write(o.someComputedData());
	o.doSomething();
but type definition is explicitely pointed.

As an example, defining a list/node type in Oberon would look like:
	TYPE
	    Node = POINTER TO NodeData;
	    NodeData = RECORD
		next	: Node;
		value	: int;
	    END ;
(Oberon records are a mix of D structs and classes: value types like structs, but with inheritance and runtime-type method dispatch.)
Then, if Oberon had 'const', it could use the same syntax as for pointed arrays, for instance, to apply const on either a "class instance" (pointer to object data) or to the data properly speaking.
I'm not advocating for having D define classes that way ;-) Not even that D allows it as an alternative, just to be able to apply const on elements of the target type (*). Rather, I mean that a seemingly good idea (implicit referencing of class defs) may lead to unexpected consequences in practical coding.


Denis

(*) For instance:
	alias class(NodeData) Node;

-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com