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?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

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

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

This is fantastic news.  I'm really happy to know you guys are making progress on this.

So if I understand this right:

* "final int*" is an immutable pointer that points to mutable data,

* "const int*" is a mutable pointer to immutable data, but that data
*may* be mutable in another context (ie: const((new int[10]).ptr)) and

* "const! int*" means "seriously, this *will not* change".

In any case, great to know things are moving along :)

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> This is fantastic news.  I'm really happy to know you guys are making
> progress on this.

Thank you! In fact, it did take an embarrassingly long time to implement something within all of the self-imposed constraints, but now we're really happy with the result.

> So if I understand this right:
> 
> * "final int*" is an immutable pointer that points to mutable data,

Yes. For example:

int a, b;
final int * p = &a;
*p = 5; // fine
p = &b; // error! Cannot rebind final symbol!

> * "const int*" is a mutable pointer to immutable data, but that data
> *may* be mutable in another context (ie: const((new int[10]).ptr)) and

Exactly. For example:

int a;
const int * p = &a;
*p = 5; // error! Cannot modify const data!
a = 5; // yah, modify data under the feet of p

This is a great feature for calling functions and providing "isolated" interfaces. For example, say you write a function

void print(char[]);

You want to clarify to the caller that you NEVER modify their data. So you define the function as:

void print(const char[]);

Then callers can call print with mutable or immutable data; it makes no difference to print.

Unlike in C++, it takes much more effort to cast away constness, and the results are never well-defined.

> * "const! int*" means "seriously, this *will not* change".

Right. For example:

int a;
const! int* p = &a; // error! cannot convert int* to const! int*
final int b = 42;
const! int* p1 = &b; // yah, b is truly immutable
const! int* p2 = new const! int; // yah



Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Daniel Keep wrote:
> 
>> This is fantastic news.  I'm really happy to know you guys are making
>> progress on this.
> 
> 
> Thank you! In fact, it did take an embarrassingly long time to implement something within all of the self-imposed constraints, but now we're really happy with the result.
> 
>> So if I understand this right:
>>
>> * "final int*" is an immutable pointer that points to mutable data,
> 
> 
> Yes. For example:
> 
> int a, b;
> final int * p = &a;
> *p = 5; // fine
> p = &b; // error! Cannot rebind final symbol!
> 
>> * "const int*" is a mutable pointer to immutable data, but that data
>> *may* be mutable in another context (ie: const((new int[10]).ptr)) and
> 
> 
> Exactly. For example:
> 
> int a;
> const int * p = &a;
> *p = 5; // error! Cannot modify const data!
> a = 5; // yah, modify data under the feet of p
> 
> This is a great feature for calling functions and providing "isolated" interfaces. For example, say you write a function
> 
> void print(char[]);
> 
> You want to clarify to the caller that you NEVER modify their data. So you define the function as:
> 
> void print(const char[]);
> 
> Then callers can call print with mutable or immutable data; it makes no difference to print.
> 
> Unlike in C++, it takes much more effort to cast away constness, and the results are never well-defined.
> 
>> * "const! int*" means "seriously, this *will not* change".
> 
> 
> Right. For example:
> 
> int a;
> const! int* p = &a; // error! cannot convert int* to const! int*
> final int b = 42;
> const! int* p1 = &b; // yah, b is truly immutable
> const! int* p2 = new const! int; // yah
> 
> 
> 
> Andrei


... and return values: "const char[] immutableTextProp()" ?

Just a thought on the const! syntax; it looks somewhat odd, and perhaps too much like template syntax?  How about calling one of the "const" types "readonly" or "view" instead?

On Thu, 15 Mar 2007 23:45:05 -0700, kris wrote:

> Andrei Alexandrescu (See Website For Email) wrote:
>> Daniel Keep wrote:
>> 
>>> This is fantastic news.  I'm really happy to know you guys are making progress on this.
>> 
>> Thank you! In fact, it did take an embarrassingly long time to implement something within all of the self-imposed constraints, but now we're really happy with the result.
>> 
>>> So if I understand this right:
>>>
>>> * "final int*" is an immutable pointer that points to mutable data,
>> 
>> Yes. For example:
>> 
>> int a, b;
>> final int * p = &a;
>> *p = 5; // fine
>> p = &b; // error! Cannot rebind final symbol!
>> 
>>> * "const int*" is a mutable pointer to immutable data, but that data
>>> *may* be mutable in another context (ie: const((new int[10]).ptr)) and
>> 
>> Exactly. For example:
>> 
>> int a;
>> const int * p = &a;
>> *p = 5; // error! Cannot modify const data!
>> a = 5; // yah, modify data under the feet of p
>> 
>> This is a great feature for calling functions and providing "isolated" interfaces. For example, say you write a function
>> 
>> void print(char[]);
>> 
>> You want to clarify to the caller that you NEVER modify their data. So you define the function as:
>> 
>> void print(const char[]);
>> 
>> Then callers can call print with mutable or immutable data; it makes no difference to print.
>> 
>> Unlike in C++, it takes much more effort to cast away constness, and the results are never well-defined.
>> 
>>> * "const! int*" means "seriously, this *will not* change".
>> 
>> Right. For example:
>> 
>> int a;
>> const! int* p = &a; // error! cannot convert int* to const! int*
>> final int b = 42;
>> const! int* p1 = &b; // yah, b is truly immutable
>> const! int* p2 = new const! int; // yah

I'm not sure about that last one. Does this mean that p2 points to an int that cannot change and p2 itself can no longer be changed? And what is the value in the int that p2 points to?

Can you do this sort of thing ...

 int x = 5;
 const! int* p2 = new const! int(x);

meaning that p2 now points to a 'final' int whose value is 5, plus p2 can never be changed now either.


> ... and return values: "const char[] immutableTextProp()" ?

Hmmmm... does "const char[] X" mean that X.ptr can change, X.length can never change and the data pointed to by X.ptr can never change? Or is "can never" too strong? Is it more that code within the scope of the declaration is not allowed to change those things?

> Just a thought on the const! syntax; it looks somewhat odd, and perhaps too much like template syntax?  How about calling one of the "const" types "readonly" or "view" instead?

Yes! "const!" is bad form. Really bad. Horrible in fact. Just make it a new keyword please, without using non-alpha characters. Such as "readonly", "immutable", "keepyourgrubbyhandsoff", ... anything but using "!".

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
16/03/2007 6:01:40 PM

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.

Does this last category include some of the current use of D const -- a value which is not modifiable, *even in theory*, and may not even have any run-time existence at all -- the C equivalent being a #defined constant.

IMHO (b) should be 'readonly' and (c) should be 'const'.
But this may be because I'm a physicist, and for me a constant is something like the speed of light, and C++'s const_cast always seemed utterly nonsensical.

void alabama() {  // Actually compiles! Someone should be shot for this.
   const double PI = 3.14159265358;
   *const_cast<double *>(&PI) = 4.0;
}

Whereas 'readonly' seems to be a much better match for (b). Although it's an extra keyword, it seems to me that the concept discussed here is sufficiently fundamental to justify an extra keyword. Especially if we have a chance to rid of 'lazy'.

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


Thanks for the update:

BTW:

const!(char[])

Looks to much like a template to me, I'd imagine some syntax phasers would have a harder time then necessary.

-Joel

Don Clugston wrote:
> 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);

Presumably this can also be an immutable view of immutable (case c) data?

>> c) "superconst" - denoted as "const!" or "super const": type qualifier meaning that the data is genuinely unmodifiable.
> 
> Does this last category include some of the current use of D const -- a value which is not modifiable, *even in theory*, and may not even have any run-time existence at all -- the C equivalent being a #defined constant.
> 
> IMHO (b) should be 'readonly' and (c) should be 'const'.
[snip]
> Whereas 'readonly' seems to be a much better match for (b). Although it's an extra keyword, it seems to me that the concept discussed here is sufficiently fundamental to justify an extra keyword. Especially if we have a chance to rid of 'lazy'.

vote++;

'const' should really means "constant". A new keyword is more than justified here.

janderson wrote:
> BTW:
> 
> const!(char[])
> 
> Looks to much like a template to me, I'd imagine some syntax phasers would have a harder time then necessary.

If you mean parsers, I don't think that'll be much of a problem. 'const' is a keyword, template names are not. If you use a syntax-highlighting reader you'll also see the difference between const!(char[]) and foo!(char[]) immediately, for the same reason.

(This is not to be construed as support for the "const!" syntax. I just dislike for different reasons ;) )