• Alex Burton <alexiub mac.com> Mar 18 2007

Alex Burton <alexiub mac.com> writes:

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.