Extended Type Design.
Alex Burton
alexiub at mac.com
Sun Mar 18 02:26:13 PDT 2007
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.
More information about the Digitalmars-d
mailing list