www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Extended Type Design.

Andrei Alexandrescu (See Website For Email) Wrote:

 Bruno Medeiros wrote:
 What is the status of the experimental designs for the "storage classes" 
 manipulation that Andrei and others where thinking of for D. The last I 
 heard from it was Andrei's max suggestion from his max design challenge, 
 however, I think that suggestion may suffer from some problems in 
 regards to the "maxtype" requirement, plus it is wholly incomplete in 
 regards to how storage classes interact between each other. Like Andrei 
 said, what is a "const inout lazy const char[]", if valid at all? Is 
 there any news here? Is there a working(aka complete) design?

We have talked about a design. In short, the intent is to define three flavors of immutability: a) final - a simple storage class controlling the immutability of the bits allocated for the symbol per se; b) const - type qualifier meaning an immutable view of an otherwise modifiable data. const does not control the bits of the object, only the storage addressed indirectly by it (transitively); c) "superconst" - denoted as "const!" or "super const": type qualifier meaning that the data is genuinely unmodifiable. There is talk about deprecating lazy if it's best implemented via other mechanisms. There is also talk about deprecating "inout" in favor of "ref" on grounds that the often-useful "inout const" is likely to become #1 reason for bashing D. To read a declaration like "const inout lazy const char[]", you can first parenthesize it appropriately: const(inout(lazy(const(char[])))) The lazy thing is really a delegate that returns a const char[]. The inout around it passes that delegate by reference, and the const at the top makes the delegate immutable. Andrei

I didn't see any discussion of how a member function is to be marked as being const or non const, as in C++. Does that mean that there are plans to make the compiler figure out which methods are const by itself ? To do this successfully will require some way of expressing aggregation. So that the compiler can distinguish between a reference that a class may hold simply to 'look at' another class from a reference that it holds representing a 'is part of' relationship. In C++ agregation could be expressed by simply not using a pointer, or if polymorphism or other reasons to use a pointer required, an aggregate pointer could be defined, such as : template <typename T> class aggregate_ptr { T * p; //dtors ctors etc. const T * operator->() const { return p; } T * operator->() { return p; } }; Here operator -> is overloaded to so that use of this pointer as a member variable is a way of expressing aggregation. ie the pointed to class is considered part of the class the pointer is part of for const purposes.
Mar 18 2007