On Tue, 30 Nov 2010 23:57:04 +0100
Fawzi Mohamed <[email protected]> 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
