On 1-dic-10, at 12:10, spir wrote:
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.
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
