tail const

[Fawzi Mohamed]

On 1-dic-10, at 12:10, spir wrote:

> 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.

yes indeed, but I would say (as I have just argued in another post)  
that having a weak const would be useful also for structures, at least  
for the user (while maybe possible it would be difficult for the user  
to build a weak const for a structure, as it implies defining another  
equivalent structure with different access qualifiers).

>
>
> Denis
>
> (*) For instance:
> 	alias class(NodeData) Node;
>
> -- -- -- -- -- -- --
> vit esse estrany ☣
>
> spir.wikidot.com
>