www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Extended Type Design.

reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Mar 14 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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 


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
Mar 15 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.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

 
 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/
Mar 15 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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
Mar 15 2007
parent reply kris <foo bar.com> writes:
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?
Mar 15 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
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
Mar 16 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 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 "!".


You can use "super const". We should be really really careful about 
adding new keywords; D already has tons, and I have a feeling we don't 
want it to become Cobol or dBase.

If there are ways to stay away from new keywords, we'll do so. I do 
realize that no matter the syntax, there will be people who won't like 
it. But avoiding adding keywords liberally is an overriding desideratum.


Andrei
Mar 16 2007
next sibling parent reply mike <vertex gmx.at> writes:
Am 16.03.2007, 10:19 Uhr, schrieb Andrei Alexandrescu (See Website For  =

Email) <SeeWebsiteForEmail erdani.org>:


 You can use "super const". We should be really really careful about  =



 adding new keywords; D already has tons, and I have a feeling we don't=


  =


 want it to become Cobol or dBase.

 If there are ways to stay away from new keywords, we'll do so. I do  =



 realize that no matter the syntax, there will be people who won't like=


  =


 it. But avoiding adding keywords liberally is an overriding desideratu=


m.

 Andrei


Why not "const final" or "final const"?

(a) .. final
(b) .. const
(c) .. const final / final const

"super" is for calling constructors and that should be the only use for =
 =

this keyword.

-mike

-- =

Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/=
mail/
Mar 16 2007
next sibling parent torhu <fake address.dude> writes:
mike wrote:

 Why not "const final" or "final const"?
 
 (a) .. final
 (b) .. const
 (c) .. const final / final const
 
 "super" is for calling constructors and that should be the only use for  
 this keyword.


Wouldn't a "final const" or "const final" pointer be like using const 
for both the pointer and the value in C?

// D
int x = 5;
const final int* p = &x;

// C
int x = 5;
const int * const p = &x;
Mar 16 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
mike wrote:

 Am 16.03.2007, 10:19 Uhr, schrieb Andrei Alexandrescu (See Website
 For Email) <SeeWebsiteForEmail erdani.org>:
 

 You can use "super const". We should be really really careful about
  adding new keywords; D already has tons, and I have a feeling we
 don't want it to become Cobol or dBase.
 
 If there are ways to stay away from new keywords, we'll do so. I do
  realize that no matter the syntax, there will be people who won't
 like it. But avoiding adding keywords liberally is an overriding
 desideratum.
 
 
 Andrei


 
 Why not "const final" or "final const"?
 
 (a) .. final (b) .. const (c) .. const final / final const


Because final const and super const express very different realities.


 "super" is for calling constructors and that should be the only use
 for this keyword.


 From your email I see you are Austrian, so I'm surprised. :o) German is 
the most synthetic (as opposed to analytical) language in use, and has 
the admirable property of building precise terms by combining smaller 
polysemous terms.


Andrei
Mar 16 2007
parent mike <vertex gmx.at> writes:
Am 16.03.2007, 18:59 Uhr, schrieb Andrei Alexandrescu (See Website For  =

Email) <SeeWebsiteForEmail erdani.org>:


 Because final const and super const express very different realities.


*scratches head*
Oh ... I didn't know that final const already HAD a meaning.


  From your email I see you are Austrian, so I'm surprised. :o) German =


is  =


 the most synthetic (as opposed to analytical) language in use, and has=


  =


 the admirable property of building precise terms by combining smaller =


 =


 polysemous terms.


Yeah, I'm Austrian, living in the land that has been named after the chi=
ef  =

 from battlestar galactica, so I don't really speak german :) We have ou=
r  =

own language, basically, that's why the rest of the german-speaking worl=
d  =

can't understand us. Like the people from Switzerland can't be understoo=
d  =

by anyone but themselves.

I like the idea of combining keywords to give them a new meaning, just  =

using "super" for two totally unrelated concepts worries me a bit. "scop=
e"  =

for instance is great: It has two meanings, but they're completely  =

related. But using super once as a call and once as a sort of amplifier =
 =

for const seems kind of random. Also I can't help myself but "super cons=
t"  =

just sounds a bit ridiculous to me:

' super duper =FCber const int i =3D 3; // Holy constant, batman!

Sorry :)

Anyway, I have no better idea, so go for it!

-mike

-- =

Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/=
mail/
Mar 16 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 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 "!".


 
 You can use "super const". We should be really really careful about 
 adding new keywords; D already has tons, and I have a feeling we don't 
 want it to become Cobol or dBase.
 
 If there are ways to stay away from new keywords, we'll do so. I do 
 realize that no matter the syntax, there will be people who won't like 
 it. But avoiding adding keywords liberally is an overriding desideratum.
 
 
 Andrei


So instead of making D like Cobol we make it like APL ? :/
I don't think the problem of Cobol was *having* too many keywords, but 
rather forcing you to *use* lots of keywords for the simplest things. 
(Disclaimer: I don't actually know Cobol, I'm imagining it to be like 
Pascal, but worse)
So we should have that in consideration when talking about D. In fact, I 
think that any general idea of "adding more keywords is bad" is somewhat 
pernicious: every case should be examined in itself. In some cases it 
could be worth it, in others not.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 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 "!".


 You can use "super const". We should be really really careful about 
 adding new keywords; D already has tons, and I have a feeling we don't 
 want it to become Cobol or dBase.

 If there are ways to stay away from new keywords, we'll do so. I do 
 realize that no matter the syntax, there will be people who won't like 
 it. But avoiding adding keywords liberally is an overriding desideratum.


 Andrei


 
 So instead of making D like Cobol we make it like APL ? :/
 I don't think the problem of Cobol was *having* too many keywords, but 
 rather forcing you to *use* lots of keywords for the simplest things. 
 (Disclaimer: I don't actually know Cobol, I'm imagining it to be like 
 Pascal, but worse)


No. Ada is like Pascal, but worse :oO.

Cobol has 420 keywords.


 So we should have that in consideration when talking about D. In fact, I 
 think that any general idea of "adding more keywords is bad" is somewhat 
 pernicious: every case should be examined in itself. In some cases it 
 could be worth it, in others not.


I agree.


Andrei
Mar 16 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 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?


Good point. There is a little exception here. People expect that when 
they write:

const char[] str = "Hi!";

they can't modify str nor its characters. So they expect str to be final 
as well. We then arrange that if const appears in a data definition, 
that data is automatically made final as well. So the above is 
equivalent to:

final const char[] str = "Hi!";

If you don't want str to be final, do this:

const(char[]) str = "Hi!";


 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.


Yes, you can.


 ... 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?


See the exception above. But now consider a function:

void say(const char[] data)
{
   ...
}

The bits of data are a private copy of say, so they can be changed 
discretionarily (if that's a word). But the bits pointed to by data do 
not belong to say, so they can't be written.

If say wants to be fancy, it can look like this:

void say(final const char[] data)
{
   ...
}

Then data can't be even rebound. The "final" being a storage class, it 
doesn't appear in the function signature (e.g., in the interface file).



Andrei
Mar 16 2007
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 02:25:24 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Derek Parnell wrote:

 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?


 
 Good point. 


<G> But you didn't answer my question? What is the value of the int to
which p2 is pointing?


 There is a little exception here. 


Oh no ... alarms start to sound when I see 'exceptions'. Is it not possible
to eliminate this exception?


 People expect that when 
 they write:
 
 const char[] str = "Hi!";
 
 they can't modify str nor its characters. So they expect str to be final 
 as well. We then arrange that if const appears in a data definition, 
 that data is automatically made final as well. So the above is 
 equivalent to:
 
 final const char[] str = "Hi!";


Are you saying "People expect that when they write ... and so that's what
we are going to have D do for them."?

Let's see if I got this ...

  const char[] str = "Hi!";  // Neither 'str' nor it contents can
                             // be changed.
  final const char[] str2 = "Hi again"; // Means the same as above syntax.

  const char*  chr = "Hi!";  // 'chr' can be changed but the chars
                             // it points to cannot be changed.

  final const char*  chr2 = "Hi!";  // 'chr2' can be not be changed
                               // and neither can its chars.

I hope I got this wrong because that is a easy bug maker.
 

 If you don't want str to be final, do this:
 
 const(char[]) str = "Hi!";


You have got to be kidding! This is starting to get unreadable again. As a
simple person, if I didn't want something to be 'final', I wouldn't use the
'final' keyword. But you are saying that if I don't want 'final', I not
only have to avoid using 'final', I also have to put some of the phrase
(and I know I'll never remember which parts) in parenthesis. But wait ...
there's more. If I do want it to be 'final' all I have to do is not use the
'final' keyword.  Am I getting this right?

Is it not possible to make reading code simple?


 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?


 
 See the exception above. 


The EXCEPTION (alarms still ringing) seems to be saying that 'const char[]
X' means that X.ptr, X.length and the data in X's RAM cannot be changed.


 But now consider a function:
 
 void say(const char[] data)
 {
    ...
 }
 
 The bits of data are a private copy of say, so they can be changed 
 discretionarily (if that's a word). But the bits pointed to by data do 
 not belong to say, so they can't be written.
 
 If say wants to be fancy, it can look like this:
 
 void say(final const char[] data)
 {
    ...
 }


That didn't help. I'm even more confused now. Can I try? ...

  void say (const char[] data)
  {
     data[0] = 'a'; // Allowed but not passed back to caller.
     data = "ABC";  // Not allowed.
  }


 Then data can't be even rebound. The "final" being a storage class, it 
 doesn't appear in the function signature (e.g., in the interface file).


Hmmmm ... won't that cause problems for library writers who provide a
library and ".di" files?

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Fri, 16 Mar 2007 02:25:24 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 

 Derek Parnell wrote:

 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?


 Good point. 


 
 <G> But you didn't answer my question? What is the value of the int to
 which p2 is pointing?


The default value of int, which is zero.


 There is a little exception here. 


 
 Oh no ... alarms start to sound when I see 'exceptions'. Is it not possible
 to eliminate this exception?


I would love to. It is only for the sake of compatibility with existing 
code.


 People expect that when 
 they write:

 const char[] str = "Hi!";

 they can't modify str nor its characters. So they expect str to be final 
 as well. We then arrange that if const appears in a data definition, 
 that data is automatically made final as well. So the above is 
 equivalent to:

 final const char[] str = "Hi!";


 
 Are you saying "People expect that when they write ... and so that's what
 we are going to have D do for them."?


I was just trying to minimize the amount of broken code. Also, we need 
to figure what to do about this:

const int capacity = 80;

In this context const makes no sense because int does not contain 
pointers. The above should be:

final int capacity = 80;


 Let's see if I got this ...
 
   const char[] str = "Hi!";  // Neither 'str' nor it contents can
                              // be changed.
   final const char[] str2 = "Hi again"; // Means the same as above syntax.


Correct.


   const char*  chr = "Hi!";  // 'chr' can be changed but the chars
                              // it points to cannot be changed.


Correct. The pointer can be made to point anywhere, but it's looking, no 
touching.


   final const char*  chr2 = "Hi!";  // 'chr2' can be not be changed
                                // and neither can its chars.


Yes.


 I hope I got this wrong because that is a easy bug maker.


How would the bugs be introduced?


 If you don't want str to be final, do this:

 const(char[]) str = "Hi!";


 
 You have got to be kidding! This is starting to get unreadable again. As a
 simple person, if I didn't want something to be 'final', I wouldn't use the
 'final' keyword.


The problem is that many simple persons have different simple needs.

The parens actually help readability a lot when compared to C++ because 
you don't need to put several const's for complex types.


 But you are saying that if I don't want 'final', I not
 only have to avoid using 'final', I also have to put some of the phrase
 (and I know I'll never remember which parts) in parenthesis. But wait ...
 there's more. If I do want it to be 'final' all I have to do is not use the
 'final' keyword.  Am I getting this right?
 
 Is it not possible to make reading code simple?


An intuition that I see reasonable is that const by default engulfs 
everything to its right:

const char[] str = "Hi!"; // same as const(char[] str) = "Hi!";

When it engulfs the symbol, it makes it immutable, hence final. So by 
putting the parens you limit const's power.

But I'd be glad to drop this exception. I'm not sure what Walter and 
people who'll have to modify their code would say though.


 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?


 See the exception above. 


 
 The EXCEPTION (alarms still ringing)  seems to be saying that 'const char[]
 X' means that X.ptr, X.length and the data in X's RAM cannot be changed.


I am hearing it. :o)


 But now consider a function:

 void say(const char[] data)
 {
    ...
 }

 The bits of data are a private copy of say, so they can be changed 
 discretionarily (if that's a word). But the bits pointed to by data do 
 not belong to say, so they can't be written.

 If say wants to be fancy, it can look like this:

 void say(final const char[] data)
 {
    ...
 }


 
 That didn't help. I'm even more confused now. Can I try? ...
 
   void say (const char[] data)
   {
      data[0] = 'a'; // Allowed but not passed back to caller.
      data = "ABC";  // Not allowed.
   }


Now, you got it backwards: data's contents belong to the caller, and 
data's pointer belongs to the callee.


 Then data can't be even rebound. The "final" being a storage class, it 
 doesn't appear in the function signature (e.g., in the interface file).


 
 Hmmmm ... won't that cause problems for library writers who provide a
 library and ".di" files?


No.


Andrei
Mar 16 2007
next sibling parent reply Dan <murpsoft hotmail.com> writes:
Wow...

I've never put this much thought into const/final stuff.  Ultimately, the
program *cannot* prevent data in memory from being changed.  It can at best
prevent you from accidentally changing it; hence final and const declarations
mean "I don't want anyone to change these, can you raise an error if someone
tries to within D?"

Also, the problem breaks down to 'what am I declaring const?'.  If I declare:

const int* x; // is it the pointer, or the int?

This doesn't seem important until you get to:

const int[int**][]* x; // now what is it?

Ultimately, you have this problem going through each and every pointer, array
and value.  You could theoretically write this:

const int[int**][]*[char[]][3][17][3,17]* x;  and now what are you going to do?
 declare it:

final const final final const const final final final final final const?
Even final const! super const! final! const! doesn't work, in fact I agree it
makes it worse.

Good luck getting readability with that.

Ultimately, something else needs to be developed.

Perhaps a character we can use in alongside each item on the type declaration,
or we need to be able to hit the whole line in one blow.

Just my penny.
Mar 16 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Dan wrote:

 Wow...
 
 I've never put this much thought into const/final stuff.  Ultimately, the
program *cannot* prevent data in memory from being changed.  It can at best
prevent you from accidentally changing it; hence final and const declarations
mean "I don't want anyone to change these, can you raise an error if someone
tries to within D?"
 
 Also, the problem breaks down to 'what am I declaring const?'.  If I declare:
 
 const int* x; // is it the pointer, or the int?
 
 This doesn't seem important until you get to:
 
 const int[int**][]* x; // now what is it?
 
 Ultimately, you have this problem going through each and every pointer, array
and value.  You could theoretically write this:
 
 const int[int**][]*[char[]][3][17][3,17]* x;  and now what are you going to
do?  declare it:
 
 final const final final const const final final final final final const?
 Even final const! super const! final! const! doesn't work, in fact I agree it
makes it worse.
 
 Good luck getting readability with that.
 
 Ultimately, something else needs to be developed.
 
 Perhaps a character we can use in alongside each item on the type declaration,
or we need to be able to hit the whole line in one blow..
 
 Just my penny.


I'm not sure what this is meant to convey.

In any language with type constructor you are able to construct long, 
incomprehensible types. You don't need storage classes and qualifiers 
for that.


Andrei
Mar 16 2007
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 14:05:17 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Dan wrote:

 Wow...
 
 I've never put this much thought into const/final stuff.  Ultimately, the
program *cannot* prevent data in memory from being changed.  It can at best
prevent you from accidentally changing it; hence final and const declarations
mean "I don't want anyone to change these, can you raise an error if someone
tries to within D?"
 
 Also, the problem breaks down to 'what am I declaring const?'.  If I declare:
 
 const int* x; // is it the pointer, or the int?
 
 This doesn't seem important until you get to:
 
 const int[int**][]* x; // now what is it?
 
 Ultimately, you have this problem going through each and every pointer, array
and value.  You could theoretically write this:
 
 const int[int**][]*[char[]][3][17][3,17]* x;  and now what are you going to
do?  declare it:
 
 final const final final const const final final final final final const?
 Even final const! super const! final! const! doesn't work, in fact I agree it
makes it worse.
 
 Good luck getting readability with that.
 
 Ultimately, something else needs to be developed.
 
 Perhaps a character we can use in alongside each item on the type declaration,
or we need to be able to hit the whole line in one blow..
 
 Just my penny.


 
 I'm not sure what this is meant to convey.


It is trying to convey the difficultly in determining which
'final'/'const'/'super const' instance refers to which part of the
declaration.

Given ...

   int[int**][]*[char[]][3][17][3,17]* x;

and I want to make the 'x' immutable and the 'char[]' immutable, how does
one write the declaration? Where does one place the 'final'/'const'/'super
const' and where do the parenthesis go?

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Fri, 16 Mar 2007 14:05:17 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 

 Dan wrote:

 Wow...

 I've never put this much thought into const/final stuff.  Ultimately, the
program *cannot* prevent data in memory from being changed.  It can at best
prevent you from accidentally changing it; hence final and const declarations
mean "I don't want anyone to change these, can you raise an error if someone
tries to within D?"

 Also, the problem breaks down to 'what am I declaring const?'.  If I declare:

 const int* x; // is it the pointer, or the int?

 This doesn't seem important until you get to:

 const int[int**][]* x; // now what is it?

 Ultimately, you have this problem going through each and every pointer, array
and value.  You could theoretically write this:

 const int[int**][]*[char[]][3][17][3,17]* x;  and now what are you going to
do?  declare it:

 final const final final const const final final final final final const?
 Even final const! super const! final! const! doesn't work, in fact I agree it
makes it worse.

 Good luck getting readability with that.

 Ultimately, something else needs to be developed.

 Perhaps a character we can use in alongside each item on the type declaration,
or we need to be able to hit the whole line in one blow..

 Just my penny.


 I'm not sure what this is meant to convey.


 
 It is trying to convey the difficultly in determining which
 'final'/'const'/'super const' instance refers to which part of the
 declaration.
 
 Given ...
 
    int[int**][]*[char[]][3][17][3,17]* x;
 
 and I want to make the 'x' immutable and the 'char[]' immutable, how does
 one write the declaration? Where does one place the 'final'/'const'/'super
 const' and where do the parenthesis go?


final int[int**][]*[const char[]][3][17][3,17]* x;

Andrei
Mar 16 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 Given ...
 
    int[int**][]*[char[]][3][17][3,17]* x;
 
 and I want to make the 'x' immutable and the 'char[]' immutable, how does
 one write the declaration? Where does one place the 'final'/'const'/'super
 const' and where do the parenthesis go?


final int[int**][]*[ const(char[]) ][3][17][3,17]* x;
Mar 16 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 Given ...

    int[int**][]*[char[]][3][17][3,17]* x;

 and I want to make the 'x' immutable and the 'char[]' immutable, how does
 one write the declaration? Where does one place the
 'final'/'const'/'super
 const' and where do the parenthesis go?


 
 final int[int**][]*[ const(char[]) ][3][17][3,17]* x;


Hmm... I think either one of you (Walter and Andrei) got bitten by the
"you have to put parens around the type or it'll get final'ed, too"
thing, or one of you got bitten by the "is this going to make it final?
 Jeeze, I dunno; better put parens in just in case."

This makes me somewhat worried :P

	-- 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/
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:

 
 Walter Bright wrote:

 Derek Parnell wrote:

 Given ...

    int[int**][]*[char[]][3][17][3,17]* x;

 and I want to make the 'x' immutable and the 'char[]' immutable, how does
 one write the declaration? Where does one place the
 'final'/'const'/'super
 const' and where do the parenthesis go?


 final int[int**][]*[ const(char[]) ][3][17][3,17]* x;


 
 Hmm... I think either one of you (Walter and Andrei) got bitten by the
 "you have to put parens around the type or it'll get final'ed, too"
 thing, or one of you got bitten by the "is this going to make it final?
  Jeeze, I dunno; better put parens in just in case."


No, in this context the parens would be simply optional. Only when const 
occurs at top level it will engulf the symbol too.

Andrei
Mar 16 2007
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 15:54:26 -0700, Walter Bright wrote:


 Derek Parnell wrote:

 Given ...
 
    int[int**][]*[char[]][3][17][3,17]* x;
 
 and I want to make the 'x' immutable and the 'char[]' immutable, how does
 one write the declaration? Where does one place the 'final'/'const'/'super
 const' and where do the parenthesis go?


 
 final int[int**][]*[ const(char[]) ][3][17][3,17]* x;


Are you serious???? 

I want 'x' to be immutable so I need to use 'final' and place it the
furtherest away from what is is qualifying.

I want 'char[]' to be immutable so I must use 'const' and place it next to
what it is qualifying plus use parenthesis around its target too.

Why do you think that this is intuitive, consistent, and easy to read?

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 17 2007
next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Derek Parnell wrote:

 On Fri, 16 Mar 2007 15:54:26 -0700, Walter Bright wrote:

 Derek Parnell wrote:

 Given ...
 
 int[int**][]*[char[]][3][17][3,17]* x;
 
 and I want to make the 'x' immutable and the 'char[]' immutable, how does
  one write the declaration? Where does one place the 
 'final'/'const'/'super const' and where do the parenthesis go?


 final int[int**][]*[ const(char[]) ][3][17][3,17]* x;


 
 Are you serious????
 
 I want 'x' to be immutable so I need to use 'final' and place it the 
 furtherest away from what is is qualifying.
 


Or you want it to be static:

static int[int**][]*[char[]][3][17][3,17]* x;

Or you want it to be private:

private int[int**][]*[char[]][3][17][3,17]* x;

Or deprecated:

deprecated int[int**][]*[char[]][3][17][3,17]* x;

In all cases, you place the attribute the furthest away from what it qualifies.
It's quite standard in C-family languages, including D, as I'm sure you know. I
don't see why "final"/"const"/"super const" should be any different.


 I want 'char[]' to be immutable so I must use 'const' and place it next to 
 what it is qualifying plus use parenthesis around its target too.


You need it within the same "scope" as the char[]: inside the [] where the
char[] is.


 Why do you think that this is intuitive, consistent, and easy to read?


What makes you think anything to do with a 35-character type is intuitive or
easy to read? ;-)

It's consistent enough for me.

-- 
Remove ".doesnotlike.spam" from the mail address.
Mar 17 2007
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Fri, 16 Mar 2007 15:54:26 -0700, Walter Bright wrote:
 

 Derek Parnell wrote:

 Given ...

    int[int**][]*[char[]][3][17][3,17]* x;

 and I want to make the 'x' immutable and the 'char[]' immutable, how does
 one write the declaration? Where does one place the 'final'/'const'/'super
 const' and where do the parenthesis go?


 final int[int**][]*[ const(char[]) ][3][17][3,17]* x;


 
 Are you serious???? 
 
 I want 'x' to be immutable so I need to use 'final' and place it the
 furtherest away from what is is qualifying.
 
 I want 'char[]' to be immutable so I must use 'const' and place it next to
 what it is qualifying plus use parenthesis around its target too.
 
 Why do you think that this is intuitive, consistent, and easy to read?


Because you didn't suggest a better design. :o)

Andrei
Mar 17 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Dan wrote:

 Wow...
 
 I've never put this much thought into const/final stuff.  Ultimately, the
program *cannot* prevent data in memory from being changed.  It can at best
prevent you from accidentally changing it; hence final and const declarations
mean "I don't want anyone to change these, can you raise an error if someone
tries to within D?"
 
 Also, the problem breaks down to 'what am I declaring const?'.  If I declare:
 
 const int* x; // is it the pointer, or the int?
 
 This doesn't seem important until you get to:
 
 const int[int**][]* x; // now what is it?
 
 Ultimately, you have this problem going through each and every pointer, array
and value.  You could theoretically write this:
 
 const int[int**][]*[char[]][3][17][3,17]* x;  and now what are you going to
do?  declare it:
 
 final const final final const const final final final final final const?
 Even final const! super const! final! const! doesn't work, in fact I agree it
makes it worse.
 
 Good luck getting readability with that.


This:
   const int[int**][]*[char[]][3][17][3,17]* x;

is *already* unreadable (plus I don't think that [3,17] part is legal 
D).  If any reasonable programmer really did have a need for such a type 
then they would probably break it up into aliases with some sort of meaning.

--bb
Mar 16 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bill Baxter wrote:

 This:
   const int[int**][]*[char[]][3][17][3,17]* x;
 
 is *already* unreadable (plus I don't think that [3,17] part is legal 
 D).


---
$ cat test.d
import std.stdio;

void main() {
         int[3,17] x;
         writefln(typeid(typeof(x)));
}
$ dmd -run test.d
int[17]
---

http://www.digitalmars.com/d/expression.html#Expressions
---
The left operand of the , is evaluated, then the right operand is 
evaluated. The type of the expression is the type of the right operand, 
and the result is the result of the right operand.
---

This is mostly for C and C++ compatibility, AFAICT. There, it's 
typically used in macros that need it to perform multiple actions that 
can only be done in separate expressions, without having the macros 
expand to full statements.
But it's also used in one of the multiply-evaluated clauses of a loop 
statement (for example, it can be used to increment multiple counters of 
a for loop on each iteration).
It's also horribly abused as an overloaded operator in (amongst others) 
boost::lambda, where it replaces ';' for lambda expressions...
Mar 16 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 But you are saying that if I don't want 'final', I not
 only have to avoid using 'final', I also have to put some of the phrase
 (and I know I'll never remember which parts) in parenthesis. But wait ...
 there's more. If I do want it to be 'final' all I have to do is not
 use the
 'final' keyword.  Am I getting this right?

 Is it not possible to make reading code simple?


 
 An intuition that I see reasonable is that const by default engulfs
 everything to its right:
 
 const char[] str = "Hi!"; // same as const(char[] str) = "Hi!";
 
 When it engulfs the symbol, it makes it immutable, hence final. So by
 putting the parens you limit const's power.
 
 But I'd be glad to drop this exception. I'm not sure what Walter and
 people who'll have to modify their code would say though.
 ...
 Andrei


$ dmd -v1

With the v1 switch, I don't need to rewrite my code if it's already
working and isn't being updated.  And even if for some reason I do need
to rewrite my code, I'm more than happy to do it in this case, if it
gets us a sane, exception-free const system :)

Heck, with D being as easy to parse as it is, I imagine that it wouldn't
be terribly difficult for someone to write a source migration program;
IIRC, Python actually had one of these for a particular version that
broke several programs.

Yeah, it's going to catch some people, but D !is Cpp, and there will
always be things that are different.  So long as these breaking changes
are for the better, I can't imagine any reasonable person would complain[1].

	-- Daniel

[1]: Well, OK, they might complain anyway.  But it's like how I could
complain that my plans of doing car maintenance-related stuff has been
ruined by this blasted wet weather!

Considering that, as a country, we really need this sort of wet weather
more often, and I know it, it's kinda an empty complaint :P

-- 
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/
Mar 16 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:

 
 $ dmd -v1
 
 With the v1 switch, I don't need to rewrite my code if it's already
 working and isn't being updated.  And even if for some reason I do need
 to rewrite my code, I'm more than happy to do it in this case, if it
 gets us a sane, exception-free const system :)
 
 Heck, with D being as easy to parse as it is, I imagine that it wouldn't
 be terribly difficult for someone to write a source migration program;
 IIRC, Python actually had one of these for a particular version that
 broke several programs.


The python Numpy project has that too.  There have been a lot of changes 
from the old version of numpy called Numeric, but you can fix almost all 
of the common cases using a script that comes with Numpy.

I suspect the script to upgrade D code would be much much MUCH simpler 
than that.


 
 Yeah, it's going to catch some people, but D !is Cpp, and there will
 always be things that are different.  So long as these breaking changes
 are for the better, I can't imagine any reasonable person would complain[1].



 [1]: Well, OK, they might complain anyway.  But it's like how I could
 complain that my plans of doing car maintenance-related stuff has been
 ruined by this blasted wet weather!
 
 Considering that, as a country, we really need this sort of wet weather
 more often, and I know it, it's kinda an empty complaint :P


Great analogy.

--bb
Mar 16 2007
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Andrei Alexandrescu (See Website For Email) Wrote:

 Derek Parnell wrote:

 On Fri, 16 Mar 2007 02:25:24 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 




<snip>


 
 I was just trying to minimize the amount of broken code. Also, we 


<snip>


 
 An intuition that I see reasonable is that const by default engulfs 
 everything to its right:
 
 const char[] str = "Hi!"; // same as const(char[] str) = "Hi!";
 
 When it engulfs the symbol, it makes it immutable, hence final. So by 
 putting the parens you limit const's power.
 
 But I'd be glad to drop this exception. I'm not sure what Walter and 
 people who'll have to modify their code would say though.
 


<snip>


 
 The EXCEPTION (alarms still ringing)  seems to be saying that 'const char[]
 X' means that X.ptr, X.length and the data in X's RAM cannot be changed.


 
 I am hearing it. :o)
 


Ok, this maybe somewhat selfish since I haven't used D's 'const' much, but I
really have to agree with Derek -- the exceptions need to be dropped <g>

Based on past NG discussions on 'const', I believe it is so important to get
this right the first time that the exceptions need to be removed in favor of
the most intuitive and consistent syntax.

Since the current "const char[] str = 'XYZ'"; semantics would prevent both str
or its elements from being modified, we could make a reasonable assumption that
code already properly tested and running (and just recompiled with a new
compiler) would not break anyhow, correct?

Thanks,

- Dave
Mar 23 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:

 Ok, this maybe somewhat selfish since I haven't used D's 'const' much, but I
really have to agree with Derek -- the exceptions need to be dropped <g>
 
 Based on past NG discussions on 'const', I believe it is so important to get
this right the first time that the exceptions need to be removed in favor of
the most intuitive and consistent syntax.
 
 Since the current "const char[] str = 'XYZ'"; semantics would prevent both str
or its elements from being modified, we could make a reasonable assumption that
code already properly tested and running (and just recompiled with a new
compiler) would not break anyhow, correct?



I think this is a valid point.

Andrei
Mar 23 2007
parent Dave <Dave_member pathlink.com> writes:
Andrei Alexandrescu (See Website For Email) Wrote:

 Dave wrote:

 Ok, this maybe somewhat selfish since I haven't used D's 'const' much, but I
really have to agree with Derek -- the exceptions need to be dropped <g>
 
 Based on past NG discussions on 'const', I believe it is so important to get
this right the first time that the exceptions need to be removed in favor of
the most intuitive and consistent syntax.
 
 Since the current "const char[] str = 'XYZ'"; semantics would prevent both str
or its elements from being modified, we could make a reasonable assumption that
code already properly tested and running (and just recompiled with a new
compiler) would not break anyhow, correct?


 
 
 I think this is a valid point.
 


Maybe a few more justifications for getting rid of the exceptions:

- It's more effort and complexity to add the exceptions to the compiler, docs.,
etc...
- IIUC, a search-and-replace operation from 'const' to 'final' or 'final const'
could 'fix' most current source code.
- It would be better to have to add the exceptions later (based on programmer
feedback) than to add them and then have to remove them.
- The other case you mentioned (i.e.: const real MyPI = 3.14159;) should not be
a problem with most currently correct D code (like const char[] str = "XYZ";
above). Could this case (a value type constant) warrant an error with the new
compiler?

Thanks,

- Dave
Mar 24 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> 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.


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'.
Mar 16 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Mar 16 2007
next sibling parent reply sclytrack <sclytrack pi.be> writes:
 IMHO (b) should be 'readonly' and (c) should be 'const'.


[snip]

vote++


Keywords
--------

I also think keywords can be written attached to one another.
Like if you were to really call it "super const" have it called
superconst instead of super_const.

It is like the foreach_reverse that we have in D. Why not
call it foreachreverse instead.

I mean we don't write

   for_each()
   {
   }

but we write

   foreach()
   {
   }

const! is ugly.
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
sclytrack wrote:

 IMHO (b) should be 'readonly' and (c) should be 'const'.


 [snip]
 
 vote++
 
 
 Keywords
 --------
 
 I also think keywords can be written attached to one another.
 Like if you were to really call it "super const" have it called
 superconst instead of super_const.


Yet you write static const not staticconst; public static not 
publicstatic; static if and not staticif; and so on.

superconst came up too. But it creates a bad precedent. A healthier 
precedent is to synthesize phrases, not new keywords, from the existing 
keywords. Think of "static if" or "final switch". Very beautiful.


 It is like the foreach_reverse that we have in D. Why not
 call it foreachreverse instead.


Probably it's best to call it foreach reverse. It's unambiguous, easy to 
parse, does not add new keywords, and continues another nice precedent 
set by extern(language) and by scope(exit).


Andrei
Mar 16 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 sclytrack wrote:

 IMHO (b) should be 'readonly' and (c) should be 'const'.


 [snip]

 vote++


 Keywords
 --------

 I also think keywords can be written attached to one another.
 Like if you were to really call it "super const" have it called
 superconst instead of super_const.


 
 Yet you write static const not staticconst; public static not 
 publicstatic; static if and not staticif; and so on.
 
 superconst came up too. But it creates a bad precedent. A healthier 
 precedent is to synthesize phrases, not new keywords, from the existing 
 keywords. Think of "static if" or "final switch". Very beautiful.
 

 It is like the foreach_reverse that we have in D. Why not
 call it foreachreverse instead.


 
 Probably it's best to call it foreach reverse. It's unambiguous, easy to 
 parse, does not add new keywords, and continues another nice precedent 
 set by extern(language) and by scope(exit).


So you mean foreach(reverse) then?  I do like that!  You're right that 
it is quite D-like.  Too bad you weren't around back when 
foreach_reverse was introduced?   ;-)

--bb
Mar 16 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 
 So you mean foreach(reverse) then?  I do like that!  You're right that 
 it is quite D-like.  Too bad you weren't around back when 
 foreach_reverse was introduced?   ;-)


This actually came up in more general terms:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=5015

Perhaps I over-complicated it with the talk of parallelism, but the idea 
was still there :-)


Sean
Mar 16 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 Bill Baxter wrote:

 So you mean foreach(reverse) then?  I do like that!  You're right that 
 it is quite D-like.  Too bad you weren't around back when 
 foreach_reverse was introduced?   ;-)


 
 This actually came up in more general terms:
 
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.
nnounce&artnum=5015 
 
 
 Perhaps I over-complicated it with the talk of parallelism, but the idea 
 was still there :-)


You have it using foreach!(arg) syntax there.  But it's not really a 
template.  Maybe it could be, and if it were then that would be great 
syntax for it.  But otherwise it's just unprecendented.  A new special case.

But what Andrei points out is that there are two precedents for the 
keyword(subkeyword) syntax, where the possible subkeywords are 
pre-defined by the compiler and completely change the behavior of the 
keyword, or rather select very different behaviors all under the same 
general umbrella.  It's exactly what was needed for foreach and 
foreach_reverse.

--bb
Mar 16 2007
parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 Sean Kelly wrote:

 Bill Baxter wrote:

 So you mean foreach(reverse) then?  I do like that!  You're right 
 that it is quite D-like.  Too bad you weren't around back when 
 foreach_reverse was introduced?   ;-)


 This actually came up in more general terms:

 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.
nnounce&artnum=5015 


 Perhaps I over-complicated it with the talk of parallelism, but the 
 idea was still there :-)


 
 You have it using foreach!(arg) syntax there.  But it's not really a 
 template.  Maybe it could be, and if it were then that would be great 
 syntax for it.  But otherwise it's just unprecendented.  A new special 
 case.


The syntax isn't really important.  I was mostly looking for a way to 
avoid creating a new keyword while supporting multi-directional iteration.


Sean
Mar 16 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 sclytrack wrote:

 IMHO (b) should be 'readonly' and (c) should be 'const'.


 [snip]

 vote++


 Keywords
 --------

 I also think keywords can be written attached to one another.
 Like if you were to really call it "super const" have it called
 superconst instead of super_const.


 Yet you write static const not staticconst; public static not 
 publicstatic; static if and not staticif; and so on.

 superconst came up too. But it creates a bad precedent. A healthier 
 precedent is to synthesize phrases, not new keywords, from the 
 existing keywords. Think of "static if" or "final switch". Very 
 beautiful.


 It is like the foreach_reverse that we have in D. Why not
 call it foreachreverse instead.


 Probably it's best to call it foreach reverse. It's unambiguous, easy 
 to parse, does not add new keywords, and continues another nice 
 precedent set by extern(language) and by scope(exit).


 
 So you mean foreach(reverse) then?  I do like that!  You're right that 
 it is quite D-like.  Too bad you weren't around back when 
 foreach_reverse was introduced?   ;-)


Possibly even without the parens:

foreach (i ; array) { ... }

foreach reverse (i ; array) { ... }

I have a feeling Walter is unlikely to change that though :o).


Andrei
Mar 16 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 sclytrack wrote:

 IMHO (b) should be 'readonly' and (c) should be 'const'.


 [snip]

 vote++


 Keywords
 --------

 I also think keywords can be written attached to one another.
 Like if you were to really call it "super const" have it called
 superconst instead of super_const.


 Yet you write static const not staticconst; public static not 
 publicstatic; static if and not staticif; and so on.

 superconst came up too. But it creates a bad precedent. A healthier 
 precedent is to synthesize phrases, not new keywords, from the 
 existing keywords. Think of "static if" or "final switch". Very 
 beautiful.


 It is like the foreach_reverse that we have in D. Why not
 call it foreachreverse instead.


 Probably it's best to call it foreach reverse. It's unambiguous, easy 
 to parse, does not add new keywords, and continues another nice 
 precedent set by extern(language) and by scope(exit).


 So you mean foreach(reverse) then?  I do like that!  You're right that 
 it is quite D-like.  Too bad you weren't around back when 
 foreach_reverse was introduced?   ;-)


 
 Possibly even without the parens:
 
 foreach (i ; array) { ... }
 
 foreach reverse (i ; array) { ... }
 
 I have a feeling Walter is unlikely to change that though :o).
 
 
 Andrei


Except then 'reverse' would have to be a keyword too, no?
Or would you do away with parens in the extern and scope cases too?  I 
liked the suggestion because it makes foreach and its reverse variant 
less of a special case.  scope and extern can be followed by things that 
that are keyword-like but that specify a specific variation of the 
keyword.  Likewise, foreach would be the same.  But if you're going to 
special case foreach in the end anyway, I see little point.  It would 
also open the door for some sort of foreach(parallel) construct without 
having to introduce yet another underscored keyword with double-digit 
character count.

--bb
Mar 16 2007
parent Kevin Bealer <kevinbealer gmail.com> writes:
Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 sclytrack wrote:

 IMHO (b) should be 'readonly' and (c) should be 'const'.


 [snip]

 vote++


 Keywords
 --------

 I also think keywords can be written attached to one another.
 Like if you were to really call it "super const" have it called
 superconst instead of super_const.


 Yet you write static const not staticconst; public static not 
 publicstatic; static if and not staticif; and so on.

 superconst came up too. But it creates a bad precedent. A healthier 
 precedent is to synthesize phrases, not new keywords, from the 
 existing keywords. Think of "static if" or "final switch". Very 
 beautiful.


 It is like the foreach_reverse that we have in D. Why not
 call it foreachreverse instead.


 Probably it's best to call it foreach reverse. It's unambiguous, 
 easy to parse, does not add new keywords, and continues another nice 
 precedent set by extern(language) and by scope(exit).


 So you mean foreach(reverse) then?  I do like that!  You're right 
 that it is quite D-like.  Too bad you weren't around back when 
 foreach_reverse was introduced?   ;-)


 Possibly even without the parens:

 foreach (i ; array) { ... }

 foreach reverse (i ; array) { ... }

 I have a feeling Walter is unlikely to change that though :o).


 Andrei


 
 Except then 'reverse' would have to be a keyword too, no?


I think the theory is that, like scope(exit), where the 'exit' is not 
really a keyword, in the foreach xyz (...) {...} expression, there is no 
legal token that can go where 'xyz' is, so something there doesn't need 
to be special.  You could use "i" or "main" without conflicting with a 
variable or function name, for instance, because those can't appear there.

It's only in places where a user-defined identifier is legal that a 
given 'adjective' word needs to be keywords.  You could define this:

if and only if () {}  while away the hours () {}

... and not conflict with existing variables named (and, only, away, 
the, hours).

Kevin


 
 --bb
Mar 21 2007
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 sclytrack wrote:

 IMHO (b) should be 'readonly' and (c) should be 'const'.


 [snip]

 vote++


 Keywords
 --------

 I also think keywords can be written attached to one another.
 Like if you were to really call it "super const" have it called
 superconst instead of super_const.


 
 Yet you write static const not staticconst; public static not 
 publicstatic; static if and not staticif; and so on.
 
 superconst came up too. But it creates a bad precedent. A healthier 
 precedent is to synthesize phrases, not new keywords, from the existing 
 keywords. Think of "static if" or "final switch". Very beautiful.
 

 It is like the foreach_reverse that we have in D. Why not
 call it foreachreverse instead.


 
 Probably it's best to call it foreach reverse. It's unambiguous, easy to 
 parse, does not add new keywords, and continues another nice precedent 
 set by extern(language) and by scope(exit).
 
 
 Andrei


How about the '1984' syntax?

double + const int; // very very const
double + super();   // call parent-of-parent constructor

(just kidding!)

I've read the description of the three const types and it's not clear to 
me which is which.  It seems like being "immutable per se" (final) and 
"genuinely unmodifiable" are pretty much synonymous.

This may seem backwards, but it would help me to keep them apart if I 
knew how they were implemented (semantically, not necessarily in terms 
of code generation).


As I understand it, "const" means "readonly view of something", similar 
to C++'s const but without the big "disable me" button.  The data is 
live but "under glass".

"final const" means the compiler never generates code to modify the 
underlying data and can assume (cache, do constant folding on) the 
underlying data.  Almost like a #define, except that you can take the 
address of it.

"invariant" is just like const, but refers to the symbol (and by 
extension the data) rather than just the data.


I'm guessing that volatile only affects const.  An invariant object 
doesn't need it and a 'final' is also essentially compile time foldable 
and thus might not even be loaded from memory per se.  (Eventually, and 
subject to quality of implementation, etc.)  But before/after a volatile 
block, a normal "const" might need to be refreshed from memory in case 
someone else had updated?


(Feel free to tell me that some of this has been answered, and I'll look 
over the thread again.)

Kevin
Mar 21 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Kevin Bealer wrote:

 As I understand it, "const" means "readonly view of something", similar 
 to C++'s const but without the big "disable me" button.  The data is 
 live but "under glass".
 
 "final const" means the compiler never generates code to modify the 
 underlying data and can assume (cache, do constant folding on) the 
 underlying data.  Almost like a #define, except that you can take the 
 address of it.
 
 "invariant" is just like const, but refers to the symbol (and by 
 extension the data) rather than just the data.


Swap these two names.

Andrei
Mar 21 2007
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Kevin Bealer wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 sclytrack wrote:

 IMHO (b) should be 'readonly' and (c) should be 'const'.


 [snip]

 vote++


 Keywords
 --------

 I also think keywords can be written attached to one another.
 Like if you were to really call it "super const" have it called
 superconst instead of super_const.


 Yet you write static const not staticconst; public static not 
 publicstatic; static if and not staticif; and so on.

 superconst came up too. But it creates a bad precedent. A healthier 
 precedent is to synthesize phrases, not new keywords, from the 
 existing keywords. Think of "static if" or "final switch". Very 
 beautiful.


 It is like the foreach_reverse that we have in D. Why not
 call it foreachreverse instead.


 Probably it's best to call it foreach reverse. It's unambiguous, easy 
 to parse, does not add new keywords, and continues another nice 
 precedent set by extern(language) and by scope(exit).


 Andrei


 
 How about the '1984' syntax?
 
 double + const int; // very very const
 double + super();   // call parent-of-parent constructor
 
 (just kidding!)
 
 I've read the description of the three const types and it's not clear to 
 me which is which.  It seems like being "immutable per se" (final) and 
 "genuinely unmodifiable" are pretty much synonymous.
 
 This may seem backwards, but it would help me to keep them apart if I 
 knew how they were implemented (semantically, not necessarily in terms 
 of code generation).
 
 
 As I understand it, "const" means "readonly view of something", similar 
 to C++'s const but without the big "disable me" button.  The data is 
 live but "under glass".
 
 "final const" means the compiler never generates code to modify the 
 underlying data and can assume (cache, do constant folding on) the 
 underlying data.  Almost like a #define, except that you can take the 
 address of it.
 
 "invariant" is just like const, but refers to the symbol (and by 
 extension the data) rather than just the data.
 
 
 I'm guessing that volatile only affects const.  An invariant object 
 doesn't need it and a 'final' is also essentially compile time foldable 
 and thus might not even be loaded from memory per se.  (Eventually, and 
 subject to quality of implementation, etc.)  But before/after a volatile 
 block, a normal "const" might need to be refreshed from memory in case 
 someone else had updated?
 
 
 (Feel free to tell me that some of this has been answered, and I'll look 
 over the thread again.)
 
 Kevin
 


Disclaimer: My current best understanding.

Final -> You may not re-bind/re-assign to this symbol.  The data bound to this
symbol (ie, 
the object, struct, array, etc) is fully mutable.  Its a storage class of the
variable, 
and has no effect on the data itself.  Foldable if its value is a basic scalar,
such as an 
int.

Const -> Part of the type, provides a read-only view into data owned by code
elsewhere 
with a mutable referance.

Invariant -> Part of the type, guaranteed absolutely not to change. 
Essentially a 
contract of sorts.. in fact, I'm starting to think of it as an invariant{}
contract block 
which "simply" asserts the data is always in the same state as immediately
after construction.


Side effects of combinations:

'final const' -> An unbindable read-only view.  Could be useful for passing
read-only 
views of data by referance, ie: void foo (final const ref bar) -- foo cannot
modify the 
data referanced by bar, nor can it reassign bar, which would've reassigned the
original 
variable since its by ref.  (The data referanced is constant, the referance
itself -- ie 
the symbol -- is not.)

'final invariant' -> Ultimate const'ness.  An unbindable variable whose value
is a 
referance to unchanging data.

Man I can't wait for all this to finally ship, in the hopes that it will come
along with a 
thorough user manual...

-- Chris Nicholson-Sauls
Mar 22 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Frits van Bommel wrote:

 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?


Yes, super const is trivially convertible to const. Const alone really 
means "I don't care about the nature of the data, I just promise I have 
no business writing into it".


 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.


We're doomed either way. We don't want to confuse C++ programmers. Two 
levels of strength of const are more descriptive than a new keyword that 
half of the people will think it's the other way.


Andrei
Mar 16 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 We're doomed either way. We don't want to confuse C++ programmers. Two 
 levels of strength of const are more descriptive than a new keyword that 
 half of the people will think it's the other way.


True. If we have readonly and const, I expect endless confusion about 
which is which.
Mar 16 2007
parent Benji Smith <dlanguage benjismith.net> writes:
Walter Bright wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 We're doomed either way. We don't want to confuse C++ programmers. Two 
 levels of strength of const are more descriptive than a new keyword 
 that half of the people will think it's the other way.


 
 True. If we have readonly and const, I expect endless confusion about 
 which is which.


Not to mention if you also have 'readsometimes'. Nobody'll EVER figure 
that one out :)

--benji
Mar 16 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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);

 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.


Yes.


 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'.


If we get rid of lazy, I'll sacrifice a lamb :o).

We've shoved keywords like "readonly" and "view" for a while, and they 
just added more confusion than cleared, at a high cost. If (as I 
suspect) super const appears relatively infrequently, it might be fine 
to just encode it as the mildly verbose "super const". In fact, it's 
shorter than "keepyourgrubbyhandsoff". :o)


Andrei
Mar 16 2007
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 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);

 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.


 
 Yes.
 

 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'.


 
 If we get rid of lazy, I'll sacrifice a lamb :o).
 
 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)
 
 Andrei


My problem is, I don't see any connection between "don't touch" and 
"constant" except that C++ got them confused. In every other other 
context outside of C++,  "constant" means "it will not change".

Mathematically, you can "hold something constant" (even though it is 
actually a variable), but as long as it is being held constant, it can't 
change.

Suppose in a function, you have 'const' access to a global variable.
Another thread with write-access to that variable can change it, while 
the function is executing.

It makes sense for a function to have read-only access to a variable, 
and need to obtain a mutex when it wants to obtain the current value.
But that's not a constant in any reasonable sense of the word.

Don.
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Don Clugston wrote:

 My problem is, I don't see any connection between "don't touch" and 
 "constant" except that C++ got them confused. In every other other 
 context outside of C++,  "constant" means "it will not change".
 
 Mathematically, you can "hold something constant" (even though it is 
 actually a variable), but as long as it is being held constant, it can't 
 change.
 
 Suppose in a function, you have 'const' access to a global variable.
 Another thread with write-access to that variable can change it, while 
 the function is executing.
 
 It makes sense for a function to have read-only access to a variable, 
 and need to obtain a mutex when it wants to obtain the current value.
 But that's not a constant in any reasonable sense of the word.


The difference between math and computer memory is that all too often in 
the latter case you want to express modular separation very often. 
Modular separation (in this context) means that the right to modify a 
certain object is owned by some part of program, and other parts may be 
offered only a view of that memory. This is such an important concept, 
even C adopted it. All of C's library functions that take pointers are 
anontated in their signature to specify whether or not they modify their 
input or not.

You want to enforce modular mutability cheaply. If D's immutability 
features fail to achieve that, we've done nothing.


Andrei
Mar 16 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 My problem is, I don't see any connection between "don't touch" and 
 "constant" except that C++ got them confused. In every other other 
 context outside of C++,  "constant" means "it will not change".

 Mathematically, you can "hold something constant" (even though it is 
 actually a variable), but as long as it is being held constant, it 
 can't change.

 Suppose in a function, you have 'const' access to a global variable.
 Another thread with write-access to that variable can change it, while 
 the function is executing.

 It makes sense for a function to have read-only access to a variable, 
 and need to obtain a mutex when it wants to obtain the current value.
 But that's not a constant in any reasonable sense of the word.


 
 The difference between math and computer memory is that all too often in 
 the latter case you want to express modular separation very often. 
 Modular separation (in this context) means that the right to modify a 
 certain object is owned by some part of program, and other parts may be 
 offered only a view of that memory. This is such an important concept, 
 even C adopted it. All of C's library functions that take pointers are 
 anontated in their signature to specify whether or not they modify their 
 input or not.
 
 You want to enforce modular mutability cheaply. If D's immutability 
 features fail to achieve that, we've done nothing.


I don't think he's arguing against immutable views, just against calling 
it 'const' ;).

In his words, from an earlier post:
=====
Don Clugston wrote:

 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'.


=====


In fact, I think most people here will agree that the ability for a 
function to specify "I won't modify this" enforced by the compiler 
(modulo pointer casts etc.) is a good thing. Especially if, as you 
mentioned, the function can return an (im)mutable result depending on 
whether a parameter was (im)mutable without having to rewrite the 
function, since that seems to be the biggest annoyance about C++'s 
constness system.
Mar 16 2007
parent Don Clugston <dac nospam.com.au> writes:
Frits van Bommel wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 My problem is, I don't see any connection between "don't touch" and 
 "constant" except that C++ got them confused. In every other other 
 context outside of C++,  "constant" means "it will not change".

 Mathematically, you can "hold something constant" (even though it is 
 actually a variable), but as long as it is being held constant, it 
 can't change.

 Suppose in a function, you have 'const' access to a global variable.
 Another thread with write-access to that variable can change it, 
 while the function is executing.

 It makes sense for a function to have read-only access to a variable, 
 and need to obtain a mutex when it wants to obtain the current value.
 But that's not a constant in any reasonable sense of the word.


 The difference between math and computer memory is that all too often 
 in the latter case you want to express modular separation very often. 
 Modular separation (in this context) means that the right to modify a 
 certain object is owned by some part of program, and other parts may 
 be offered only a view of that memory. This is such an important 
 concept, even C adopted it. All of C's library functions that take 
 pointers are anontated in their signature to specify whether or not 
 they modify their input or not.

 You want to enforce modular mutability cheaply. If D's immutability 
 features fail to achieve that, we've done nothing.


 
 I don't think he's arguing against immutable views, just against calling 
 it 'const' ;).


Exactly. Thank you. I'm purely concerned about the name.
Mar 16 2007
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)
 
 Andrei


Really? I'd think super const would be used all the time. Anywhere a 
class has some invariant field, it'll probably be expressed as super 
const (if I'm understanding correctly that super const is the equivalent 
of #define constants in C++ or static final constants in Java).

Let me join the ranks of those who hate both versions of the new syntax. 
  const! looks either like a template or like "not const". You guys may 
think you're saving a keyword, and that might be technically correct 
from the perspective of the parser. But, for the perspective of the D 
developer, it still looks like you've introduced a new keyword, but it's 
a keyword that's A) nearly identical to another keyword, and B) contains 
a symbol. Ugh. I really. Really. Really. Hate it.

Using "super const" is also annoying because all of the other storage 
classes use a single keyword. Now we've got this weird case that uses 
two keywords. And the word "super" is now overloaded in two completely 
unrelated concepts.

(By the way, I don't like "static if" either. I think the right choice 
would have been #if, #foreach, etc. And I think C++ made a mistake by 
defining "long long" and "double double" types as well. Presumably, that 
saved some keywords, but we'd all have been better off if the types were 
defined as int8, int16, int32, int64, float32, float64, etc).

I vote for "readonly" and "const". Anything else seems like a mistake.

--benji
Mar 16 2007
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Benji Smith wrote:

 And the word "super" is now overloaded in two completely unrelated concepts.
 


Which isn't that rare, see the following link:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex

I find the following examples: auto, in, is, mixin, scope, static.

I have come to abhor the keyword "static" largely due to the above. Too bad its
various uses are unavoidably useful. <g>

But I do agree with you, in a way. After writing the following I find my
explanation somewhat unclear even to myself, but bear with me.

The problem with "super const" is that "super" modifies the other keyword,
"const", instead of saying something about the expression/statement/whatever (in
this case, the type). Even "static", in all its horror, can be seen as
specifying one of "module-level" or "compile-time". The other keywords mentioned
above use their English meaning as such an explanation, and so can be understood
without too much thought. "super const" would make "super" another "static":
lacking context, you can't be sure about about even the general meaning, let
alone the one in a specific instance.

Upon reflection it may be moot, since one probably rarely cares about keywords'
meanings without context, but I'm sure some psychologist could come up with
something about intuitiveness which affects coding speed, or whatever.

I'd be happiest to just get the feature as soon as possible; worrying about
keyword semantics can come later. Just like the abominations beginning with
"on_scope_". <g>

-- 
Remove ".doesnotlike.spam" from the mail address.
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Deewiant wrote:

 Benji Smith wrote:

 And the word "super" is now overloaded in two completely unrelated concepts.


 
 Which isn't that rare, see the following link:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex
 
 I find the following examples: auto, in, is, mixin, scope, static.
 
 I have come to abhor the keyword "static" largely due to the above. Too bad its
 various uses are unavoidably useful. <g>
 
 But I do agree with you, in a way. After writing the following I find my
 explanation somewhat unclear even to myself, but bear with me.
 
 The problem with "super const" is that "super" modifies the other keyword,
 "const", instead of saying something about the expression/statement/whatever
(in
 this case, the type). Even "static", in all its horror, can be seen as
 specifying one of "module-level" or "compile-time". The other keywords
mentioned
 above use their English meaning as such an explanation, and so can be
understood
 without too much thought. "super const" would make "super" another "static":
 lacking context, you can't be sure about about even the general meaning, let
 alone the one in a specific instance.
 
 Upon reflection it may be moot, since one probably rarely cares about keywords'
 meanings without context, but I'm sure some psychologist could come up with
 something about intuitiveness which affects coding speed, or whatever.


Working in NLP myself, I totally disagree. Natural language is rife with 
homonimy and synonimy, and we're all very, very happy with that. But in 
this case we don't even have to go that far: "super" is an adjective 
meaning primarily "of high grade or quality" and qualifies a noun. If 
there's no noun, you don't know what is "of high grade or quality". It's 
a fact, and we don't even blink.

The reality behind super const is that it expresses a stronger form of 
const. It makes a lot of sense if I dub it "super const" in natural 
language, to express it in the same way in the programming language. I 
thought that that's too verbose and devised "const!" as a shortcut 
(again with obvious conotations in natural language), but I'm thinking 
of dropping it and let type inference add "super" to "const" whenever it 
can. That should ensure exactness of the type system without verbosity 
in source code.


 I'd be happiest to just get the feature as soon as possible; worrying about
 keyword semantics can come later. Just like the abominations beginning with
 "on_scope_". <g>


Great idea. :o)


Andrei
Mar 16 2007
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Deewiant wrote:

 The problem with "super const" is that "super" modifies the other keyword, 
 "const", instead of saying something about the 
 expression/statement/whatever (in this case, the type). Even "static", in
 all its horror, can be seen as specifying one of "module-level" or
 "compile-time". The other keywords mentioned above use their English
 meaning as such an explanation, and so can be understood without too much
 thought. "super const" would make "super" another "static": lacking
 context, you can't be sure about about even the general meaning, let alone
 the one in a specific instance.
 
 Upon reflection it may be moot, since one probably rarely cares about 
 keywords' meanings without context, but I'm sure some psychologist could
 come up with something about intuitiveness which affects coding speed, or
 whatever.


 
 Working in NLP myself, I totally disagree. Natural language is rife with 
 homonimy and synonimy, and we're all very, very happy with that. But in this
 case we don't even have to go that far: "super" is an adjective meaning
 primarily "of high grade or quality" and qualifies a noun. If there's no
 noun, you don't know what is "of high grade or quality". It's a fact, and we
 don't even blink.


Oh, I didn't say I was of that opinion myself. In fact, I have a tendency to
disagree with psychology in general. <g> You're right and that's good a point.


 The reality behind super const is that it expresses a stronger form of const.
 It makes a lot of sense if I dub it "super const" in natural language, to
 express it in the same way in the programming language. I thought that that's
 too verbose and devised "const!" as a shortcut (again with obvious
 conotations in natural language), but I'm thinking of dropping it and let
 type inference add "super" to "const" whenever it can. That should ensure
 exactness of the type system without verbosity in source code.


"const!" has the advantage of being one word, but not really a new keyword.
"super const" is two words. I still can't really express why I see that as a bad
thing, but it _is_ better than adding a new keyword like "superconst" (or
"keepyourgrubbyhandsoff"). I wouldn't be opposed to something like "readonly"
though. Maybe I've just been coding too much Java recently: if I have to write
"private final static double" much more I'm going to puke. <g>

It's largely a question of what one's used to. Elsewhere in the thread the fact
that some languages have "elsif" or "elif" or equivalent instead of "else if"
was mentioned. I don't really see much of a difference, except that "elif" takes
a bit too long to process for me since the "el" -> "else" relation isn't
intuitive. But, just like an eventual "super const" (and the current "static"),
coding enough in a language with such will make it intuitive to me, and I won't
complain (much).

In general, I do agree with your view, found elsewhere in the thread, that using
existing keywords is best. That, or constructs like "scope (success)" where
success isn't a keyword. I'm just currently a bit repelled by the pair "super
const".

-- 
Remove ".doesnotlike.spam" from the mail address.
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Deewiant wrote:
[snip]


 In general, I do agree with your view, found elsewhere in the thread, that
using
 existing keywords is best. That, or constructs like "scope (success)" where
 success isn't a keyword. I'm just currently a bit repelled by the pair "super
 const".


Well how about "real const" then :oD.

I think the good news is that you don't need to type it that often. You 
type:

const char[] str = "Hi!";

and the compiler figures out the "super" part itself.


Andrei
Mar 16 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Deewiant wrote:
 [snip]
 

 In general, I do agree with your view, found elsewhere in the thread, 
 that using
 existing keywords is best. That, or constructs like "scope (success)" 
 where
 success isn't a keyword. I'm just currently a bit repelled by the pair 
 "super
 const".


 
 Well how about "real const" then :oD.
 
 I think the good news is that you don't need to type it that often. You 
 type:
 
 const char[] str = "Hi!";
 
 and the compiler figures out the "super" part itself.


Doh!  'real const'  of course... how could I leave that one out.


   'real const'
   'true const'
   'double const'
   'finally const'
   'is const'
   or
   'is finally super double true real const'

--bb
Mar 16 2007
parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Deewiant wrote:
 [snip]


 In general, I do agree with your view, found elsewhere in the thread, 
 that using
 existing keywords is best. That, or constructs like "scope (success)" 
 where
 success isn't a keyword. I'm just currently a bit repelled by the 
 pair "super
 const".


 Well how about "real const" then :oD.

 I think the good news is that you don't need to type it that often. 
 You type:

 const char[] str = "Hi!";

 and the compiler figures out the "super" part itself.


 
 Doh!  'real const'  of course... how could I leave that one out.
 
 
   'real const'
   'true const'
   'double const'
   'finally const'
   'is const'
   or
   'is finally super double true real const'


'const is back and now its really mad' ?
Mar 16 2007
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 
 Working in NLP myself, I totally disagree. Natural language is rife with 
 homonimy and synonimy, and we're all very, very happy with that. But in 
 this case we don't even have to go that far: "super" is an adjective 
 meaning primarily "of high grade or quality" and qualifies a noun. If 
 there's no noun, you don't know what is "of high grade or quality". It's 
 a fact, and we don't even blink.
 
 Andrei


I've also worked in NLP quite a bit, but I don't think the constructs of 
natural languages are necessarily healthy in artificial languages.

Many natural language constructs are only distinguishable through 
contextual analysis awareness or sense disambiguation (anaphora 
resolution and prepositional phrase attachment are among the most 
difficult to disambiguate).

Natural languages rife with ambiguity may be easy for native speakers to 
disambiguate (thanks to the semantic model we develop during early 
childhood), but those ambiguities make it more difficult for adults to 
learn new languages.

I like artificial languages to be artificial. I like them to be concise 
and unambiguous. I like them to have context-free grammars free from 
left-recursion. I don't like the word "static" to mean one thing in one 
context and something else entirely in another context. I don't like 
keywords to contain punctuation marks. And I don't like phrasal nouns 
(like "super const" or the inevitable "super duper const").

Just like highly ambiguous natural languages are difficult for adults to 
learn, I think synonymy and homonimy make it more difficult for 
professional developers to learn a new programming language.

I used to write a lot of perl code, and the constructs it borrowed from 
natural language (synonymy, homonimy, anaphora, implied words, pronouns, 
etc) are some of the things that drove me away from the language toward 


But that's just me. Not everyone will agree with my opinion, and if I'm 
not in the consensus, I'll concede. But there seem to be a lot of people 
who agree with me.

I reiterate: "const" and "readonly" are the way to go. (Methods which 
promise not to modify the values of their parameters should use 
"readonly" rather than "const" in their method signatures.)

--benji
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Working in NLP myself, I totally disagree. Natural language is rife 
 with homonimy and synonimy, and we're all very, very happy with that. 
 But in this case we don't even have to go that far: "super" is an 
 adjective meaning primarily "of high grade or quality" and qualifies a 
 noun. If there's no noun, you don't know what is "of high grade or 
 quality". It's a fact, and we don't even blink.

 Andrei


 
 I've also worked in NLP quite a bit, but I don't think the constructs of 
 natural languages are necessarily healthy in artificial languages.


[snip]

Me neither. Of course you don't want to do WSD to figure out the meaning 
of a keyword in a context. All I'm saying is that you can be expressive 
without blowing up your vocabulary by using collocations.


 I used to write a lot of perl code, and the constructs it borrowed from 
 natural language (synonymy, homonimy, anaphora, implied words, pronouns, 
 etc) are some of the things that drove me away from the language toward 



I think it's pretty clear to many in which places Perl went a little too 
far :o).


 But that's just me. Not everyone will agree with my opinion, and if I'm 
 not in the consensus, I'll concede. But there seem to be a lot of people 
 who agree with me.


I don't think so. This discussion is very small in numbers, and the 
strength of the interlocutors' arguments does not increase their number. 
  At the end of the day, if we design a good feature, people (who 
participated here or not) will be glad to use it; if not, they won't. 
And that's that.


 I reiterate: "const" and "readonly" are the way to go. (Methods which 
 promise not to modify the values of their parameters should use 
 "readonly" rather than "const" in their method signatures.)


This makes const gratuitously incompatible to C++'s const, and (worse) 
also adds a keyword that's its equivalent. I don't think this can fly.


Andrei
Mar 16 2007
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 But that's just me. Not everyone will agree with my opinion, and if 
 I'm not in the consensus, I'll concede. But there seem to be a lot of 
 people who agree with me.


 
 I don't think so. This discussion is very small in numbers, and the 
 strength of the interlocutors' arguments does not increase their number. 


What???? Blasphemy!!!!


 I reiterate: "const" and "readonly" are the way to go. (Methods which 
 promise not to modify the values of their parameters should use 
 "readonly" rather than "const" in their method signatures.)


 
 This makes const gratuitously incompatible to C++'s const, and (worse) 
 also adds a keyword that's its equivalent. I don't think this can fly.


Good point. I like kris's suggestion to get rid of the "const" keyword 
entirely and replace it with something else ("constant" seems like a 
reasonable suggestion). Here are some other synonyms for "constant":

http://thesaurus.reference.com/browse/constant

There might be something useful in there. I'm personally fond of "chronic".

:-)

--benji
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 But that's just me. Not everyone will agree with my opinion, and if 
 I'm not in the consensus, I'll concede. But there seem to be a lot of 
 people who agree with me.


 I don't think so. This discussion is very small in numbers, and the 
 strength of the interlocutors' arguments does not increase their number. 


 
 What???? Blasphemy!!!!
 

 I reiterate: "const" and "readonly" are the way to go. (Methods which 
 promise not to modify the values of their parameters should use 
 "readonly" rather than "const" in their method signatures.)


 This makes const gratuitously incompatible to C++'s const, and (worse) 
 also adds a keyword that's its equivalent. I don't think this can fly.


 
 Good point. I like kris's suggestion to get rid of the "const" keyword 
 entirely and replace it with something else ("constant" seems like a 
 reasonable suggestion). Here are some other synonyms for "constant":
 
 http://thesaurus.reference.com/browse/constant
 
 There might be something useful in there. I'm personally fond of "chronic".
 
 :-)


Believe me, I pored over thesauri for a long, long time.

Andrei
Mar 16 2007
prev sibling next sibling parent Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 This makes const gratuitously incompatible to C++'s const, and (worse) 
 also adds a keyword that's its equivalent. I don't think this can fly.


There's some experience with that: the alias and typedef declarations. 
But that experience makes me wary of doing it in a much bigger way.
Mar 16 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:



 I reiterate: "const" and "readonly" are the way to go. (Methods which 
 promise not to modify the values of their parameters should use 
 "readonly" rather than "const" in their method signatures.)


 
 This makes const gratuitously incompatible to C++'s const, and (worse) 
 also adds a keyword that's its equivalent. I don't think this can fly.


What about 'immutable' for 'really can't change'/'superconst', and const 
can stay as is?

--bb
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:


 

 I reiterate: "const" and "readonly" are the way to go. (Methods which 
 promise not to modify the values of their parameters should use 
 "readonly" rather than "const" in their method signatures.)


 This makes const gratuitously incompatible to C++'s const, and (worse) 
 also adds a keyword that's its equivalent. I don't think this can fly.


 
 What about 'immutable' for 'really can't change'/'superconst', and const 
 can stay as is?


I like it, and suggested it at a point. Walter said that it's bad 
marketing to define keywords in terms of a negative.

Andrei
Mar 16 2007
parent reply kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Bill Baxter wrote:
 

 Andrei Alexandrescu (See Website For Email) wrote:


 Benji Smith wrote:




 I reiterate: "const" and "readonly" are the way to go. (Methods 
 which promise not to modify the values of their parameters should 
 use "readonly" rather than "const" in their method signatures.)



 This makes const gratuitously incompatible to C++'s const, and 
 (worse) also adds a keyword that's its equivalent. I don't think this 
 can fly.



 What about 'immutable' for 'really can't change'/'superconst', and 
 const can stay as is?


 
 
 I like it, and suggested it at a point. Walter said that it's bad 
 marketing to define keywords in terms of a negative.


So, "invariant" is already a keyword ... what about that?

"Invariant" is currently used to stipulate a condition that must remain 
constant (or true) for the extent of the enclosing/relevant scope. Right 
now, it is used within a class only, but the semantics could presumably 
extend elsewhere too:

invariant int * p = &x;

void myFunc (invariant char[] arg) {}

in both these cases, the "invariance" should remain for the extent of 
the relevant scope?
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
kris wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Bill Baxter wrote:


 Andrei Alexandrescu (See Website For Email) wrote:


 Benji Smith wrote:




 I reiterate: "const" and "readonly" are the way to go. (Methods 
 which promise not to modify the values of their parameters should 
 use "readonly" rather than "const" in their method signatures.)



 This makes const gratuitously incompatible to C++'s const, and 
 (worse) also adds a keyword that's its equivalent. I don't think 
 this can fly.



 What about 'immutable' for 'really can't change'/'superconst', and 
 const can stay as is?



 I like it, and suggested it at a point. Walter said that it's bad 
 marketing to define keywords in terms of a negative.


 
 So, "invariant" is already a keyword ... what about that?
 
 "Invariant" is currently used to stipulate a condition that must remain 
 constant (or true) for the extent of the enclosing/relevant scope. Right 
 now, it is used within a class only, but the semantics could presumably 
 extend elsewhere too:
 
 invariant int * p = &x;
 
 void myFunc (invariant char[] arg) {}
 
 in both these cases, the "invariance" should remain for the extent of 
 the relevant scope?


I completely missed that one. I think it's a good idea to look into it 
as a candidate for a qualifier name. Thank you.

Andrei
Mar 16 2007
next sibling parent reply kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 kris wrote:


[snip]

 So, "invariant" is already a keyword ... what about that?

 "Invariant" is currently used to stipulate a condition that must 
 remain constant (or true) for the extent of the enclosing/relevant 
 scope. Right now, it is used within a class only, but the semantics 
 could presumably extend elsewhere too:

 invariant int * p = &x;

 void myFunc (invariant char[] arg) {}

 in both these cases, the "invariance" should remain for the extent of 
 the relevant scope?


 
 
 I completely missed that one. I think it's a good idea to look into it 
 as a candidate for a qualifier name. Thank you.


yw

If it gets tossed for whatever reason, It might be worthwhile renaming 
the current "invariant" to whatever is settled upon? That may reclaim a 
keyword at least.
Mar 16 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
kris wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 kris wrote:


 [snip]

 So, "invariant" is already a keyword ... what about that?

 "Invariant" is currently used to stipulate a condition that must 
 remain constant (or true) for the extent of the enclosing/relevant 
 scope. Right now, it is used within a class only, but the semantics 
 could presumably extend elsewhere too:

 invariant int * p = &x;

 void myFunc (invariant char[] arg) {}

 in both these cases, the "invariance" should remain for the extent of 
 the relevant scope?



 I completely missed that one. I think it's a good idea to look into it 
 as a candidate for a qualifier name. Thank you.




Typically with invariants in CS the meaning is that "you can change all 
you want as long as you put things back the way you found them when 
you're done".  And that's definitely not the connotation desired here.


 If it gets tossed for whatever reason, It might be worthwhile renaming 
 the current "invariant" to whatever is settled upon? That may reclaim a 
 keyword at least.


Invariant can refer to an abstract property that doesn't change, like 
"full.length + empty.length == buffer.length".  The individual 
constituents of that expression can change all they want.  So calling it 
constant/readonly/immutable doesn't make as much sense as 'invariant'.

--bb
Mar 16 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 kris wrote:

 So, "invariant" is already a keyword ... what about that?


 I completely missed that one. I think it's a good idea to look into it 
 as a candidate for a qualifier name. Thank you.


I agree. I think:

final
const
invariant

for the three cases looks pretty good.
Mar 17 2007
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 17 Mar 2007 19:09:16 -0700, Walter Bright wrote:

I'm sorry I'm so thick, but have I got the idea right yet ... ?
 

 final


 This applies only to assignments to Write-Once RAM locations. This can be
done by either the compiler or at run time depending on the amount of
knowledge the compiler has about the location's usage.


 const


 This is applied to declarations to prevent code in the same scope as the
declaration from being able to modify the item being declared.


 invariant


 This is applied to declarations to prevent code in the same application as
the declaration from being able to modify the item being declared.


As you can see, I'm confused as to how the qualifier effects which code is
allowed to change which items. Even more so when it comes to reference
items ... 'cos I'm not sure how to use these qualifiers to specify whether
the reference and/or the data being referenced can be changed, and by whom.


-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 17 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 final


  This applies only to assignments to Write-Once RAM locations. This can be
 done by either the compiler or at run time depending on the amount of
 knowledge the compiler has about the location's usage.


No. This applies to rebinding of a name:
	final x = 3;
	x = 4;		// error, x is final
i.e. final applies to the declared name, not the type.


 const


  This is applied to declarations to prevent code in the same scope as the
 declaration from being able to modify the item being declared.


No. This means that it is a readonly view of data - other views of the 
same data may change it.
	char[] s = "hello".dup;
	const char[] t = s;
	t[0] = 'j';	// error, const char[] is a readonly view
	s[0] = 'j';	// ok
	writefln(t);	// prints "jello"
	t = s[1..2];	// ok, as t is not final
Note that const applies to the type, not the name.


 invariant


  This is applied to declarations to prevent code in the same application as
 the declaration from being able to modify the item being declared.


Almost right. It isn't the declaration, but the *type* that is 
invariant. Invariant applies to the type, not the name.


 As you can see, I'm confused as to how the qualifier effects which code is
 allowed to change which items. Even more so when it comes to reference
 items ... 'cos I'm not sure how to use these qualifiers to specify whether
 the reference and/or the data being referenced can be changed, and by whom.


'final' is a storage class, like 'static'. It doesn't apply to the type 
of the symbol, only the symbol itself.
'const' and 'invariant' apply to the type of the symbol, not the symbol.
Mar 17 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Derek Parnell wrote:


[snip]

 invariant


  This is applied to declarations to prevent code in the same 
 application as
 the declaration from being able to modify the item being declared.


 
 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


By the way, "invariant" is a lifesaver. Everybody and their sister in 
the coffee shop liked it at the first sight. The girl at the counter 
asked for kris' email :o).

Yes, "invariant" is essentially a synonym to "constant", but here are 
two simple mnemonic devices to remember which is which:

a) "const" is shorter because it's used more often;

b) "const" is similar to C++'s homonym.

Easier to remember than perl's $|.


Andrei
Mar 17 2007
parent reply Alex Burton <alexibu mac.com> writes:
Andrei Alexandrescu (See Website For Email) Wrote:


 Walter Bright wrote:

 Derek Parnell wrote:


 [snip]

 invariant


  This is applied to declarations to prevent code in the same 
 application as
 the declaration from being able to modify the item being declared.


 
 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


 
 By the way, "invariant" is a lifesaver. Everybody and their sister in 
 the coffee shop liked it at the first sight. The girl at the counter 
 asked for kris' email :o).
 
 Yes, "invariant" is essentially a synonym to "constant", but here are 
 two simple mnemonic devices to remember which is which:
 
 a) "const" is shorter because it's used more often;
 
 b) "const" is similar to C++'s homonym.
 
 Easier to remember than perl's $|.
 
 
 Andrei


Another option I'd like to have at least considered is the finding of a
character that can be used to denote const.
Adding various constnesses to all the code could easily add a whole lot of
typing to the task of getting things done in D.

Could we find a unicode character that wouldn't be too much trouble for editors
to insert ? Might mean that D starts to require unicode source - but is that
such a bad thing ?

Are there any ascii characters that can be found that wont confuse the parser ?
- like how the use of ! works for templates

Alex
Mar 18 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Alex Burton wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:
 

 Walter Bright wrote:

 Derek Parnell wrote:


 [snip]

 invariant


  This is applied to declarations to prevent code in the same 
 application as
 the declaration from being able to modify the item being declared.


 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


 By the way, "invariant" is a lifesaver. Everybody and their sister in 
 the coffee shop liked it at the first sight. The girl at the counter 
 asked for kris' email :o).

 Yes, "invariant" is essentially a synonym to "constant", but here are 
 two simple mnemonic devices to remember which is which:

 a) "const" is shorter because it's used more often;

 b) "const" is similar to C++'s homonym.

 Easier to remember than perl's $|.


 Andrei


 
 Another option I'd like to have at least considered is the finding of a
character that can be used to denote const.
 Adding various constnesses to all the code could easily add a whole lot of
typing to the task of getting things done in D.
 
 Could we find a unicode character that wouldn't be too much trouble for
editors to insert ? Might mean that D starts to require unicode source - but is
that such a bad thing ?
 
 Are there any ascii characters that can be found that wont confuse the parser
? - like how the use of ! works for templates


Type inference will reduce the need for littering code with "const" a 
great deal (when compared to today's C++ code, at least). You just write:

auto var = expression;

and the const will propagate. Initial experience will show whether this 
is enough.


Andrei
Mar 18 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Alex Burton wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:


 Walter Bright wrote:

 Derek Parnell wrote:


 [snip]

 invariant


  This is applied to declarations to prevent code in the same 
 application as
 the declaration from being able to modify the item being declared.


 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


 By the way, "invariant" is a lifesaver. Everybody and their sister in 
 the coffee shop liked it at the first sight. The girl at the counter 
 asked for kris' email :o).

 Yes, "invariant" is essentially a synonym to "constant", but here are 
 two simple mnemonic devices to remember which is which:

 a) "const" is shorter because it's used more often;

 b) "const" is similar to C++'s homonym.

 Easier to remember than perl's $|.


 Andrei


 Another option I'd like to have at least considered is the finding of 
 a character that can be used to denote const.
 Adding various constnesses to all the code could easily add a whole 
 lot of typing to the task of getting things done in D.

 Could we find a unicode character that wouldn't be too much trouble 
 for editors to insert ? Might mean that D starts to require unicode 
 source - but is that such a bad thing ?

 Are there any ascii characters that can be found that wont confuse the 
 parser ? - like how the use of ! works for templates


 
 Type inference will reduce the need for littering code with "const" a 
 great deal (when compared to today's C++ code, at least). You just write:
 
 auto var = expression;
 
 and the const will propagate. Initial experience will show whether this 
 is enough.


What about the ability to deduce only parts of a type?

Declaring types is also a kind of documentation / assertion that can 
help maintainers of the code later.   I might want to specify const and 
let the type be deduced, or I might want to specify the type I'm 
expecting and let const be deduced.

Maybe declaration followed by is-test will be necessary for those cases. 
  If they aren't too common I guess that's ok.  But I would hate to see
    auto var = expression;
    assert(is(non_const_typeof(var)==Something));
become a standard idiom.

... how will one do that is() check for base type sans type constructors?

--bb
Mar 18 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Alex Burton wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:


 Walter Bright wrote:

 Derek Parnell wrote:


 [snip]

 invariant


  This is applied to declarations to prevent code in the same 
 application as
 the declaration from being able to modify the item being declared.


 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


 By the way, "invariant" is a lifesaver. Everybody and their sister 
 in the coffee shop liked it at the first sight. The girl at the 
 counter asked for kris' email :o).

 Yes, "invariant" is essentially a synonym to "constant", but here 
 are two simple mnemonic devices to remember which is which:

 a) "const" is shorter because it's used more often;

 b) "const" is similar to C++'s homonym.

 Easier to remember than perl's $|.


 Andrei


 Another option I'd like to have at least considered is the finding of 
 a character that can be used to denote const.
 Adding various constnesses to all the code could easily add a whole 
 lot of typing to the task of getting things done in D.

 Could we find a unicode character that wouldn't be too much trouble 
 for editors to insert ? Might mean that D starts to require unicode 
 source - but is that such a bad thing ?

 Are there any ascii characters that can be found that wont confuse 
 the parser ? - like how the use of ! works for templates


 Type inference will reduce the need for littering code with "const" a 
 great deal (when compared to today's C++ code, at least). You just write:

 auto var = expression;

 and the const will propagate. Initial experience will show whether 
 this is enough.


 
 What about the ability to deduce only parts of a type?
 
 Declaring types is also a kind of documentation / assertion that can 
 help maintainers of the code later.   I might want to specify const and 
 let the type be deduced, or I might want to specify the type I'm 
 expecting and let const be deduced.
 
 Maybe declaration followed by is-test will be necessary for those cases. 
  If they aren't too common I guess that's ok.  But I would hate to see
    auto var = expression;
    assert(is(non_const_typeof(var)==Something));
 become a standard idiom.
 
 ... how will one do that is() check for base type sans type constructors?


assert(is(const typeof(var) == typeof(var)));

Only time will show whether this will be needed frequently. I don't 
think so: in general var will engender an error upon first mutation, 
which is close to its definition.

Andrei
Mar 18 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Alex Burton wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:


 Walter Bright wrote:

 Derek Parnell wrote:


 [snip]

 invariant


  This is applied to declarations to prevent code in the same 
 application as
 the declaration from being able to modify the item being declared.


 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


 By the way, "invariant" is a lifesaver. Everybody and their sister 
 in the coffee shop liked it at the first sight. The girl at the 
 counter asked for kris' email :o).

 Yes, "invariant" is essentially a synonym to "constant", but here 
 are two simple mnemonic devices to remember which is which:

 a) "const" is shorter because it's used more often;

 b) "const" is similar to C++'s homonym.

 Easier to remember than perl's $|.


 Andrei


 Another option I'd like to have at least considered is the finding 
 of a character that can be used to denote const.
 Adding various constnesses to all the code could easily add a whole 
 lot of typing to the task of getting things done in D.

 Could we find a unicode character that wouldn't be too much trouble 
 for editors to insert ? Might mean that D starts to require unicode 
 source - but is that such a bad thing ?

 Are there any ascii characters that can be found that wont confuse 
 the parser ? - like how the use of ! works for templates


 Type inference will reduce the need for littering code with "const" a 
 great deal (when compared to today's C++ code, at least). You just 
 write:

 auto var = expression;

 and the const will propagate. Initial experience will show whether 
 this is enough.


 What about the ability to deduce only parts of a type?

 Declaring types is also a kind of documentation / assertion that can 
 help maintainers of the code later.   I might want to specify const 
 and let the type be deduced, or I might want to specify the type I'm 
 expecting and let const be deduced.

 Maybe declaration followed by is-test will be necessary for those 
 cases.  If they aren't too common I guess that's ok.  But I would hate 
 to see
    auto var = expression;
    assert(is(non_const_typeof(var)==Something));
 become a standard idiom.

 ... how will one do that is() check for base type sans type constructors?


 
 assert(is(const typeof(var) == typeof(var)));
 
 Only time will show whether this will be needed frequently. I don't 
 think so: in general var will engender an error upon first mutation, 
 which is close to its definition.
 
 Andrei


Why not just
   const auto var = expression;
?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 19 2007
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Sat, 17 Mar 2007 21:33:16 -0700, Walter Bright wrote:


 Derek Parnell wrote:

 final


  This applies only to assignments to Write-Once RAM locations. This can be
 done by either the compiler or at run time depending on the amount of
 knowledge the compiler has about the location's usage.


 
 No. This applies to rebinding of a name:
 	final x = 3;
 	x = 4;		// error, x is final
 i.e. final applies to the declared name, not the type.
 

 const


  This is applied to declarations to prevent code in the same scope as the
 declaration from being able to modify the item being declared.


 
 No. This means that it is a readonly view of data - other views of the 
 same data may change it.
 	char[] s = "hello".dup;
 	const char[] t = s;
 	t[0] = 'j';	// error, const char[] is a readonly view
 	s[0] = 'j';	// ok
 	writefln(t);	// prints "jello"
 	t = s[1..2];	// ok, as t is not final
 Note that const applies to the type, not the name.
 

 invariant


  This is applied to declarations to prevent code in the same application as
 the declaration from being able to modify the item being declared.


 
 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.
 

 As you can see, I'm confused as to how the qualifier effects which code is
 allowed to change which items. Even more so when it comes to reference
 items ... 'cos I'm not sure how to use these qualifiers to specify whether
 the reference and/or the data being referenced can be changed, and by whom.


 
 'final' is a storage class, like 'static'. It doesn't apply to the type 
 of the symbol, only the symbol itself.
 'const' and 'invariant' apply to the type of the symbol, not the symbol.


I'm sure its just a terminology problem I'm having, but I still can't
understand what you are trying to tell me. I'm sorry I'm so thick!

To me the word 'type' refers to the data type associated with a symbol -
like 'int', 'float', 'char[]' , etc... So when you say "'const' and
'invariant' apply to the type" it sounds like you are saying that 'const'
prevents a symbol from changing types - which doesn't make sense to me. In
D, a symbol can never change types once it has been declared. 

So, I'm now wondering if by "type" you are actually meaning the data
represented by the symbol and not its data-type. However that doesn't quite
make sense either because that's what I was saying but you disagreed with
me!?

Please bear with me. Oh, and anyone else can chime in to help make it clear
to me too, please.

Let's take 'final' again. 

Walter said:

 No. This applies to rebinding of a name:
 	final x = 3;
 	x = 4;		// error, x is final
 i.e. final applies to the declared name, not the type.


Now by 'binding' I assume you mean 'having the compiler associate a value
with a symbol'.

So "final x = 3" is sort of equivalent to C's "#define x (3)", but in D
there are scope and data-type implications. 

I expect that in D we will also be able to do ...

  final double z = 4.288392;

but what about things like ...

  int y = 3;
  final x = y;
  final q = someFunc();

And is ...

    final s = "qwerty";
    char[] t = s;

identical to ...

    char[] t = "qwerty".dup;


I presume this would fail at compile time ...

    void XYZZY(inout char[] x) { . . . }
    . . .
    final s = "qwerty";
    XYZZY(s);


*****
Okay, now let's revisit 'const'.

I said ...

  This is applied to declarations to prevent code in the same scope as the
 declaration from being able to modify the item being declared.




And you said ...

 No. This means that it is a readonly view of data - other views of the 
 same data may change it.
 	char[] s = "hello".dup;
 	const char[] t = s;
 	t[0] = 'j';	// error, const char[] is a readonly view
 	s[0] = 'j';	// ok
 	writefln(t);	// prints "jello"
 	t = s[1..2];	// ok, as t is not final
 Note that const applies to the type, not the name.


Apart from the last sentence, which still confuses the hell out of me, I
think we almost are saying the same thing.

Using your example code, I was saying that the declaration "const char[] t"
means that you can't change 't' (i.e. t.ptr and t.length cannot be altered)
but you can change the data that t.ptr points to.  However, I see by your
explanation that I got this the wrong way around. I now read you saying
that 'const char[] t' means that program can change t.ptr and/or t.length
but it cannot use 't' to change the data it points to. I said nothing about
getting to the data via another symbol. Also, I see that you are saying
"final const char[] t" means that neither 't' nor its data can be altered.

Is there any difference between "final const char[] t" and "const final
char[] t"?

Is "const int x = 4" and "final int x = 4" mean the same thing (not a
reference type this time)? 

Would "final const x = 5" compile? Would it mean anything different from
just 'final' or just 'const'?

It would seem that 'const' is primarily used to protect referenced data
rather than the reference itself. Is that right?


Will this be allowed ...

   void XYZZY(const char[] s)
   {
      char[] t;
      t = s;   // fails here?
      t[0] = 'a';
   }

*****
And now to 'invariant' ...

You said ...

 It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


I have no idea what you mean by that statement! I still can't see that
data-types can change. But maybe you mean data rather than data-type, but
then isn't that what 'const' is doing? And I'm sure you *do not* mean that
somehow you can rename symbols during compilation!? So I can't see what is
"invariant" - as in - what is "not changing".

If I code "invariant char[] t", ...
  (A) are changes to t.ptr/t.length prevented? 

  (B) are changes to the data that 't' points to prevented? 

How is 'invariant' different from 'final'?

How is 'invariant' different from 'const'?

How is 'invariant' different from 'final const'?


Is combining 'invariant' with 'final' and/or 'const' meaningful? If so,
how?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
19/03/2007 11:55:33 AM
Mar 18 2007
next sibling parent reply James Dennett <jdennett acm.org> writes:
Derek Parnell wrote:

 On Sat, 17 Mar 2007 21:33:16 -0700, Walter Bright wrote:
 

 Derek Parnell wrote:

 final


  This applies only to assignments to Write-Once RAM locations. This can be
 done by either the compiler or at run time depending on the amount of
 knowledge the compiler has about the location's usage.


 No. This applies to rebinding of a name:
 	final x = 3;
 	x = 4;		// error, x is final
 i.e. final applies to the declared name, not the type.


 const


  This is applied to declarations to prevent code in the same scope as the
 declaration from being able to modify the item being declared.


 No. This means that it is a readonly view of data - other views of the 
 same data may change it.
 	char[] s = "hello".dup;
 	const char[] t = s;
 	t[0] = 'j';	// error, const char[] is a readonly view
 	s[0] = 'j';	// ok
 	writefln(t);	// prints "jello"
 	t = s[1..2];	// ok, as t is not final
 Note that const applies to the type, not the name.


 invariant


  This is applied to declarations to prevent code in the same application as
 the declaration from being able to modify the item being declared.


 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


 As you can see, I'm confused as to how the qualifier effects which code is
 allowed to change which items. Even more so when it comes to reference
 items ... 'cos I'm not sure how to use these qualifiers to specify whether
 the reference and/or the data being referenced can be changed, and by whom.


 'final' is a storage class, like 'static'. It doesn't apply to the type 
 of the symbol, only the symbol itself.
 'const' and 'invariant' apply to the type of the symbol, not the symbol.


 
 I'm sure its just a terminology problem I'm having, but I still can't
 understand what you are trying to tell me. I'm sorry I'm so thick!
 
 To me the word 'type' refers to the data type associated with a symbol -
 like 'int', 'float', 'char[]' , etc... So when you say "'const' and
 'invariant' apply to the type" it sounds like you are saying that 'const'
 prevents a symbol from changing types - which doesn't make sense to me. In
 D, a symbol can never change types once it has been declared. 


It's just saying that "T" and "const T" are different types
(unless T was already const); they have different permitted
operations.

I'd have to say that I find Walter's ideas on const/final
to be rather... distinctive... and we've debated terminology
at some length but with no resolution.  It's his language,
he can use terms as he wishes.  It may impede communication.
This may be a case of "final" being a thing that Walter likes
to think of as a storage class rather than a type modifier
(though in a more general sense storage classes are just a
special/restricted case of type modifiers).

"final", I think, is a workaround for handling types
that are accessed through automatically-dereferenced
GC'd pointers in D.  The auto-deref property hides the
actual type of those pointers from us, so we can't const-
qualify them; we just end up adding const to the type to
which they point.  C++ doesn't work this way, and so
const does everything that final does and more in C++.
It's just different.  If you want indirection via a
reference/pointer, C++ makes you say so, but gives you
the chance to apply type modifiers to that pointer.  D
does it invisibly, but then requires extra syntax to be
able to stop the name being rebindable.

-- James
Mar 18 2007
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Sun, 18 Mar 2007 20:46:58 -0700, James Dennett wrote:

Walter says 

 "'const' and 'invariant' apply to the type"





 It's just saying that "T" and "const T" are different types
 (unless T was already const); they have different permitted
 operations.


Oh?! Is that all. That is easy to understand, but it does not help me
understand how Walter sees it or 'invariant' being used.

So "int", "const int" and "invariant int" are all different types and as
such have in-built rules concerning implicit conversions etc...That's fine.
I can understand that. But what then are the built-rules? Are the rules
different for POD, Objects, and Arrays? 


 I'd have to say that I find Walter's ideas on const/final
 to be rather... distinctive... and we've debated terminology
 at some length but with no resolution.  It's his language,
 he can use terms as he wishes.  It may impede communication.


I'm fine with that too. Sure, its Walter (and Andrei's) language and that
can make up syntax and keywords as they see fit. I only hope that they get
some good documentation experts to help people like me understand it.


 This may be a case of "final" being a thing that Walter likes
 to think of as a storage class rather than a type modifier
 (though in a more general sense storage classes are just a
 special/restricted case of type modifiers).
 
 "final", I think, is a workaround for handling types
 that are accessed through automatically-dereferenced
 GC'd pointers in D.  The auto-deref property hides the
 actual type of those pointers from us, so we can't const-
 qualify them; we just end up adding const to the type to
 which they point.  C++ doesn't work this way, and so
 const does everything that final does and more in C++.
 It's just different.  If you want indirection via a
 reference/pointer, C++ makes you say so, but gives you
 the chance to apply type modifiers to that pointer.  D
 does it invisibly, but then requires extra syntax to be
 able to stop the name being rebindable.


Interesting ... but what does all that sound like in English <G>

I don't really know C++ all that well so I don't quite get the comparisons.
Can anyone explain this without referring to other programming languages,
please? Just common everyday English would be nice - oh, but with example
<G>.

But let's see if I can translate it first ...

"storage class" means how something's value is stored in RAM. Which could
be in the data space or as immediate literals in the code space. Thus
'final' is a description of how the compiler sees the value stored in the
program. One rule is that it is impossible for any code to alter the value
associated (bound) a 'final' symbol. For all practical purposes, from the
compiler's point of view, the symbol *is* the value. When applied to
reference types, the symbol's value is the reference and not that which is
being referenced.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
19/03/2007 3:24:59 PM
Mar 18 2007
prev sibling parent reply jovo <jovo at.home> writes:
James Dennett Wrote:

 
 "final", I think, is a workaround for handling types
 that are accessed through automatically-dereferenced
 GC'd pointers in D.  The auto-deref property hides the
 actual type of those pointers from us, so we can't const-
 qualify them; we just end up adding const to the type to
 which they point.  C++ doesn't work this way, and so
 const does everything that final does and more in C++.
 It's just different.  If you want indirection via a
 reference/pointer, C++ makes you say so, but gives you
 the chance to apply type modifiers to that pointer.  D
 does it invisibly, but then requires extra syntax to be
 able to stop the name being rebindable.
 


But I think it is'nt key point here. As I understand, const
will afect all from the specified stage in the reference chain,
unlike C++ const?

Code analogous to this legal C++ code will be compile time error?

struct S { int *x; };
    
int a = 12;
S s = { &a };
const S *p = &s;
*p->x = 20;  // will be error?

jovo
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
jovo wrote:

 James Dennett Wrote:

 "final", I think, is a workaround for handling types
 that are accessed through automatically-dereferenced
 GC'd pointers in D.  The auto-deref property hides the
 actual type of those pointers from us, so we can't const-
 qualify them; we just end up adding const to the type to
 which they point.  C++ doesn't work this way, and so
 const does everything that final does and more in C++.
 It's just different.  If you want indirection via a
 reference/pointer, C++ makes you say so, but gives you
 the chance to apply type modifiers to that pointer.  D
 does it invisibly, but then requires extra syntax to be
 able to stop the name being rebindable.


 
 But I think it is'nt key point here. As I understand, const
 will afect all from the specified stage in the reference chain,
 unlike C++ const?
 
 Code analogous to this legal C++ code will be compile time error?
 
 struct S { int *x; };
     
 int a = 12;
 S s = { &a };
 const S *p = &s;
 *p->x = 20;  // will be error?


Yes. D's const is transitive.

Andrei
Mar 19 2007
parent reply jovo <jovo at.home> writes:
Andrei Alexandrescu (See Website For Email) Wrote:

 
 Yes. D's const is transitive.
 


So:
finall = stage0_nontransitive_const?
const = stage1_transitive_const?

May be beter to separete concepts?

Do we need stage1_const?
Do we need nontransitive_const?

jovo
Mar 19 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
jovo wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:

 Yes. D's const is transitive.


 
 So:
 finall = stage0_nontransitive_const?
 const = stage1_transitive_const?


If I understand the above properly, yes.


 May be beter to separete concepts?
 
 Do we need stage1_const?
 Do we need nontransitive_const?


So rarely that we decided they can be ruled out. They'd complicate the 
type system gravely, for very little benefit.

Andrei
Mar 19 2007
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Derek Parnell wrote:

 On Sat, 17 Mar 2007 21:33:16 -0700, Walter Bright wrote:
 

 Derek Parnell wrote:

 final


  This applies only to assignments to Write-Once RAM locations. This can be
 done by either the compiler or at run time depending on the amount of
 knowledge the compiler has about the location's usage.


 No. This applies to rebinding of a name:
 	final x = 3;
 	x = 4;		// error, x is final
 i.e. final applies to the declared name, not the type.


 const


  This is applied to declarations to prevent code in the same scope as the
 declaration from being able to modify the item being declared.


 No. This means that it is a readonly view of data - other views of the 
 same data may change it.
 	char[] s = "hello".dup;
 	const char[] t = s;
 	t[0] = 'j';	// error, const char[] is a readonly view
 	s[0] = 'j';	// ok
 	writefln(t);	// prints "jello"
 	t = s[1..2];	// ok, as t is not final
 Note that const applies to the type, not the name.


 invariant


  This is applied to declarations to prevent code in the same application as
 the declaration from being able to modify the item being declared.


 Almost right. It isn't the declaration, but the *type* that is 
 invariant. Invariant applies to the type, not the name.


 As you can see, I'm confused as to how the qualifier effects which code is
 allowed to change which items. Even more so when it comes to reference
 items ... 'cos I'm not sure how to use these qualifiers to specify whether
 the reference and/or the data being referenced can be changed, and by whom.


 'final' is a storage class, like 'static'. It doesn't apply to the type 
 of the symbol, only the symbol itself.
 'const' and 'invariant' apply to the type of the symbol, not the symbol.


 
 I'm sure its just a terminology problem I'm having, but I still can't
 understand what you are trying to tell me. I'm sorry I'm so thick!
 


It's likely the following:
By "It doesn't apply to the type of the symbol, only the symbol itself." 
it means it applies to the immediate-value, and by "apply to the type of 
the symbol, not the symbol" it means it applies to the referenced-data, 
where:

"immediate-value" means the value that is changed on assignments, which 
in primitives is the primitive value, and on references is the pointer 
(memory location).
"referenced-data" is the data obtained through references (i.e., data 
pointed to)

IMO I think that terminology is faulty, since, for starters, one can 
have an expression that is not assignable (like the return value of 
functions), which is the same as being 'final', yet there is no 
associated symbol. The same applies to saying 'final' "applies to 
rebinding of a name", like in the example below:


 
 Walter said:

 No. This applies to rebinding of a name:
 	final x = 3;
 	x = 4;		// error, x is final
 i.e. final applies to the declared name, not the type.


 
 Now by 'binding' I assume you mean 'having the compiler associate a value
 with a symbol'.
 
 So "final x = 3" is sort of equivalent to C's "#define x (3)", but in D
 there are scope and data-type implications. 
 


The differences are that the 'final' variable exists at runtime (unlike 
#define) and as such the initializer doesn't have to be a constant, and 
the var can be referenced.


 I expect that in D we will also be able to do ...
 
   final double z = 4.288392;
 
 but what about things like ...
 
   int y = 3;
   final x = y;
   final q = someFunc();
 


Yes.


 And is ...
 
     final s = "qwerty";
     char[] t = s;
 
 identical to ...
 
     char[] t = "qwerty".dup;
 


No, I don't think so, why would it be?


 
 I presume this would fail at compile time ...
 
     void XYZZY(inout char[] x) { . . . }
     . . .
     final s = "qwerty";
     XYZZY(s);
 
 


Yup.


 *****
 Okay, now let's revisit 'const'.
 
 I said ...

  This is applied to declarations to prevent code in the same scope as the
 declaration from being able to modify the item being declared.




 
 And you said ...

 No. This means that it is a readonly view of data - other views of the 
 same data may change it.
 	char[] s = "hello".dup;
 	const char[] t = s;
 	t[0] = 'j';	// error, const char[] is a readonly view
 	s[0] = 'j';	// ok
 	writefln(t);	// prints "jello"
 	t = s[1..2];	// ok, as t is not final
 Note that const applies to the type, not the name.


 
 Apart from the last sentence, which still confuses the hell out of me, I
 think we almost are saying the same thing.
 
 Using your example code, I was saying that the declaration "const char[] t"
 means that you can't change 't' (i.e. t.ptr and t.length cannot be altered)
 but you can change the data that t.ptr points to.  


That's what 'final' does (i.e. "t.ptr and t.length cannot be altered").


However, I see by your
 explanation that I got this the wrong way around. I now read you saying
 that 'const char[] t' means that program can change t.ptr and/or t.length
 but it cannot use 't' to change the data it points to. I said nothing about
 getting to the data via another symbol. Also, I see that you are saying
 "final const char[] t" means that neither 't' nor its data can be altered.
 
 Is there any difference between "final const char[] t" and "const final
 char[] t"?


Nope.


 Is "const int x = 4" and "final int x = 4" mean the same thing (not a
 reference type this time)? 
 


I suspect no, since 'const' for primitives is either ignored or not 
allowed, but I'm not sure what Andrei is planning it to be.


 Would "final const x = 5" compile? Would it mean anything different from
 just 'final' or just 'const'?
 


Same as above, dunno.


 It would seem that 'const' is primarily used to protect referenced data
 rather than the reference itself. Is that right?
 


Yup.


 And now to 'invariant' ...
 


For what I got 'invariant' means the data doesn't change at all, like 
compile time constants, or ROM data. But I didn't understand if it 
applies to the "immediate-value" only (like 'final'), or transitively to 
the referenced data too (like 'const'). Clarify?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 19 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bruno Medeiros wrote:

 
 For what I got 'invariant' means the data doesn't change at all, like 
 compile time constants, or ROM data. But I didn't understand if it 
 applies to the "immediate-value" only (like 'final'), or transitively to 
 the referenced data too (like 'const'). Clarify?
 


Its my understanding that 'invariant' becomes part of the type, like 'const'. 
So in your 
terms, it applies to "referenced data".

invariant ANSWER = 42 ;

bool question (invariant int guess) {
   return guess is ANSWER;
}

;)

-- Chris Nicholson-Sauls
Mar 19 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bruno has answered your specific questions, so I'll take a more general 
tack.

A symbol is a name to which is 'bound' a value.

static int x = 3;

'3' is the value.
'int' is the type.
'x' is the symbol.
'static' is the storage class.

Here, we bind a new value to the symbol x:
     x = 4;

A storage class originally meant where the symbol is stored, such as in 
the data segment, on the stack, in a register, or in ROM. It's been 
generalized a bit since then. The main way to tell a storage class apart 
is that:
1) a storage class applies to the symbol
2) a type is independent of storage class, i.e. you cannot create a type 
that is "pointer to static" or "array of extern". Storage classes do not 
affect overloading, nor type deduction.

'invariant' and 'const' are type modifiers (aka type constructors), 
which mean when they are applied to a type, a new type is created that 
is a combination.

'invariant' is a guarantee that any data of that type will never change. 
'const' is a guarantee that any data of that type will never be modified 
through a reference to that type (though other, non-const references to 
that type can modify the data).
Mar 20 2007
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Mar 2007 16:01:35 -0700, Walter Bright wrote:



 A symbol is a name to which is 'bound' a value.


 ...


 Here, we bind a new value to the symbol x:
      x = 4;


I used to use the verb 'to assign' for this concept. I guess that's still
okay or must I modernize <G>
 

 static int x = 3;
 
 '3' is the value.
 'int' is the type.
 'x' is the symbol.
 'static' is the storage class.
 
 
 A storage class originally meant where the symbol is stored, such as in 
 the data segment, on the stack, in a register, or in ROM. It's been 
 generalized a bit since then. The main way to tell a storage class apart 
 is that:
 1) a storage class applies to the symbol


"to the symbol"?  Don't you mean "to the data that the symbol represents"?
In the case above, the symbol is 'x', and I don't think 'x' is being stored
anywhere except in the compiler's internal tables, and I'm sure 'static'
isn't referring to the compiler's internals.

 

 'invariant' is a guarantee that any data of that type will never change. 


 class Foo 
 { 
   int a; 
   char[] s; 
   this(char[] d)
   {
       s = d.dup;
       a = s.length;
   }
 }
 invariant Foo f = new Foo("nice");

 f.a = 1; // fails??? changing f's data
 f.s = "bad"; // fails??? changing f's data
 f.s.length = 1; // fails??? changing f's data
 f.s[0] = 'r'; // okay ??? not changing f's data

 f = new Foo("rabbit"); // okay 'cos 'f' is a reference
                        // and not the object???


 'const' is a guarantee that any data of that type will never be modified 
 through a reference to that type (though other, non-const references to 
 that type can modify the data).


 const Foo f = new Foo("nice");
       Foo g = f;

 f.a = 1; // fails??? changing f's data
 g.a = 1; // okay??? Using 'g' and not 'f'.
 f.s = "bad"; // fails??? changing f's data
 g.s = "bad"; // okay??? Using 'g' and not 'f'.
 f.s.length = 1; // fails??? changing f's data
 g.s.length = 1; // okay??? Using 'g' and not 'f'.
 f.s[0] = 'r'; // okay ??? not changing f's data

 f = new Foo("rabbit"); // okay 'cos 'f' is a reference
                        // and not the object???

 (*(&f)).a = 1; // okay??? access through f's address and not 'f'.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/03/2007 10:39:07 AM
Mar 20 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Tue, 20 Mar 2007 16:01:35 -0700, Walter Bright wrote:
 
 

 A symbol is a name to which is 'bound' a value.


  ...
 

 Here, we bind a new value to the symbol x:
      x = 4;


 
 I used to use the verb 'to assign' for this concept. I guess that's still
 okay or must I modernize <G>


You may want to modernize. "Assign" doesn't quite catch the notion of 
indirect reference, and from a couple of posts I understand that this is 
a source of confusion.

A very useful way to see "int x = 4;" is that the symbol x is bound to 
the Platonic number 4. The 4 itself cannot change. You can rebind x by, 
say, writing ++x. That unbinds x from Plato 4 and binds it to Plato 5. 
Once this is clear, the notions of values and references clarifies a lot.


 static int x = 3;

 '3' is the value.
 'int' is the type.
 'x' is the symbol.
 'static' is the storage class.


 A storage class originally meant where the symbol is stored, such as in 
 the data segment, on the stack, in a register, or in ROM. It's been 
 generalized a bit since then. The main way to tell a storage class apart 
 is that:
 1) a storage class applies to the symbol


 
 "to the symbol"?  Don't you mean "to the data that the symbol represents"?
 In the case above, the symbol is 'x', and I don't think 'x' is being stored
 anywhere except in the compiler's internal tables, and I'm sure 'static'
 isn't referring to the compiler's internals.


The meaning was simple. When you say "poor fella Jim", "poor" applies to 
Jim, not to "fella".


 'invariant' is a guarantee that any data of that type will never change. 


 
  class Foo 
  { 
    int a; 
    char[] s; 
    this(char[] d)
    {
        s = d.dup;
        a = s.length;
    }
  }
  invariant Foo f = new Foo("nice");
 
  f.a = 1; // fails??? changing f's data
  f.s = "bad"; // fails??? changing f's data
  f.s.length = 1; // fails??? changing f's data
  f.s[0] = 'r'; // okay ??? not changing f's data


They all fail. The last fails because invariance is transitive. All that 
could be done is to rebind f to another invariant object.


Andrei
Mar 20 2007
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Mar 2007 17:24:49 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Derek Parnell wrote:

 On Tue, 20 Mar 2007 16:01:35 -0700, Walter Bright wrote:
 

 A symbol is a name to which is 'bound' a value.


  ...
 

 Here, we bind a new value to the symbol x:
      x = 4;


 
 I used to use the verb 'to assign' for this concept. I guess that's still
 okay or must I modernize <G>


 
 You may want to modernize. "Assign" doesn't quite catch the notion of 
 indirect reference, 


Okay, if you say so, but I'm not having an issue with the concept of
assigning value to something directly or indirectly.


 and from a couple of posts I understand that this is 
 a source of confusion.


Not for me, but thanks anyway.


 A very useful way to see "int x = 4;" is that the symbol x is bound to 
 the Platonic number 4. The 4 itself cannot change. You can rebind x by, 
 say, writing ++x. That unbinds x from Plato 4 and binds it to Plato 5. 


Huh? Just looks like a fancy way of saying 'x' first gets assigned the
value 4 then later, using ++x, gets assigned the value 5. By whatever, I'll
not get hung up as I think we are on the same track here.


 Once this is clear, the notions of values and references clarifies a lot.


It does? How? If pressed, I'd say that the only difference between 'assign'
and 'bind' is that 'assign' maybe implies an 'assignment statement' was
used to change the value, but 'bind' doesn't care how the change is caused.


 static int x = 3;

 '3' is the value.
 'int' is the type.
 'x' is the symbol.
 'static' is the storage class.


 A storage class originally meant where the symbol is stored, such as in 
 the data segment, on the stack, in a register, or in ROM. It's been 
 generalized a bit since then. The main way to tell a storage class apart 
 is that:
 1) a storage class applies to the symbol


 
 "to the symbol"?  Don't you mean "to the data that the symbol represents"?
 In the case above, the symbol is 'x', and I don't think 'x' is being stored
 anywhere except in the compiler's internal tables, and I'm sure 'static'
 isn't referring to the compiler's internals.


 
 The meaning was simple. When you say "poor fella Jim", "poor" applies to 
 Jim, not to "fella".


Oh, okay ... its not a 'static int' (a type) but a 'static x' (a value
represented by the symbol 'x').
 

 'invariant' is a guarantee that any data of that type will never change. 


 
  class Foo 
  { 
    int a; 
    char[] s; 
    this(char[] d)
    {
        s = d.dup;
        a = s.length;
    }
  }
  invariant Foo f = new Foo("nice");
 
  f.a = 1; // fails??? changing f's data
  f.s = "bad"; // fails??? changing f's data
  f.s.length = 1; // fails??? changing f's data
  f.s[0] = 'r'; // okay ??? not changing f's data


 
 They all fail. The last fails because invariance is transitive. All that 
 could be done is to rebind f to another invariant object.


Thanks. I'm just trying to get all this straight in my mind. So the
definition should be more along the lines of ...

'invariant' is a guarantee that any data accessible from that type will
never change. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/03/2007 11:52:49 AM
Mar 20 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Tue, 20 Mar 2007 17:24:49 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 

 Derek Parnell wrote:

 On Tue, 20 Mar 2007 16:01:35 -0700, Walter Bright wrote:


 A symbol is a name to which is 'bound' a value.


  ...


 Here, we bind a new value to the symbol x:
      x = 4;


 I used to use the verb 'to assign' for this concept. I guess that's still
 okay or must I modernize <G>


 You may want to modernize. "Assign" doesn't quite catch the notion of 
 indirect reference, 


 
 Okay, if you say so, but I'm not having an issue with the concept of
 assigning value to something directly or indirectly.
 

 and from a couple of posts I understand that this is 
 a source of confusion.


 
 Not for me, but thanks anyway.
 

 A very useful way to see "int x = 4;" is that the symbol x is bound to 
 the Platonic number 4. The 4 itself cannot change. You can rebind x by, 
 say, writing ++x. That unbinds x from Plato 4 and binds it to Plato 5. 


 
 Huh? Just looks like a fancy way of saying 'x' first gets assigned the
 value 4 then later, using ++x, gets assigned the value 5. By whatever, I'll
 not get hung up as I think we are on the same track here.
 

 Once this is clear, the notions of values and references clarifies a lot.


 
 It does? How? If pressed, I'd say that the only difference between 'assign'
 and 'bind' is that 'assign' maybe implies an 'assignment statement' was
 used to change the value, but 'bind' doesn't care how the change is caused.


No. The difference is major. The binding to Platonic values clarifies 
that values are exactly the same thing as references to immutable 
objects. Once that is understood, it's very easy to understand all of 
D's immutability minutiae.


Andrei
Mar 20 2007
prev sibling next sibling parent jovo <jovo at.home> writes:
Andrei Alexandrescu (See Website For Email) Wrote:

 You may want to modernize. "Assign" doesn't quite catch the notion of 
 indirect reference, and from a couple of posts I understand that this is 
 a source of confusion.
 
 A very useful way to see "int x = 4;" is that the symbol x is bound to 
 the Platonic number 4. The 4 itself cannot change. You can rebind x by, 
 say, writing ++x. That unbinds x from Plato 4 and binds it to Plato 5. 
 Once this is clear, the notions of values and references clarifies a lot.
 


Actually, when I use this term:

struct S {
    int a;
    int* b;
}

const S s;
s.a = 1;                        // not allowed
s.b = some_address;       // not allowed
*s.b = 1;                      // not allowed
s = some_S;                  // allowed

don't look alogical, and what is more important, produces,
I think at first look, better result.

jovo
Mar 20 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Tue, 20 Mar 2007 16:01:35 -0700, Walter Bright wrote:



 A symbol is a name to which is 'bound' a value.


  ...


 Here, we bind a new value to the symbol x:
      x = 4;


 I used to use the verb 'to assign' for this concept. I guess that's still
 okay or must I modernize <G>


 
 You may want to modernize. "Assign" doesn't quite catch the notion of 
 indirect reference, and from a couple of posts I understand that this is 
 a source of confusion.
 


Huh, " "Assign" doesn't quite catch the notion of indirect reference", 
what do you mean by that? I too was thinking that "assign" is a much 
better term than "binding".


 A very useful way to see "int x = 4;" is that the symbol x is bound to 
 the Platonic number 4. The 4 itself cannot change. You can rebind x by, 
 say, writing ++x. That unbinds x from Plato 4 and binds it to Plato 5. 
 Once this is clear, the notions of values and references clarifies a lot.
 


Dear Gods. Yes, that conceptualization is correct, but again, how is it 
any better than "assign"/"assignability"?

   A very useful way to see "int x = 4;" is that the symbol x is 
assigned to the value 4. You can reassign x by writing ++x. That assigns 
x to the value x+1.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Tue, 20 Mar 2007 16:01:35 -0700, Walter Bright wrote:



 A symbol is a name to which is 'bound' a value.


  ...


 Here, we bind a new value to the symbol x:
      x = 4;


 I used to use the verb 'to assign' for this concept. I guess that's 
 still
 okay or must I modernize <G>


 You may want to modernize. "Assign" doesn't quite catch the notion of 
 indirect reference, and from a couple of posts I understand that this 
 is a source of confusion.


 
 Huh, " "Assign" doesn't quite catch the notion of indirect reference", 
 what do you mean by that? I too was thinking that "assign" is a much 
 better term than "binding".
 

 A very useful way to see "int x = 4;" is that the symbol x is bound to 
 the Platonic number 4. The 4 itself cannot change. You can rebind x 
 by, say, writing ++x. That unbinds x from Plato 4 and binds it to 
 Plato 5. Once this is clear, the notions of values and references 
 clarifies a lot.


 
 Dear Gods. Yes, that conceptualization is correct, but again, how is it 
 any better than "assign"/"assignability"?
 
   A very useful way to see "int x = 4;" is that the symbol x is assigned 
 to the value 4. You can reassign x by writing ++x. That assigns x to the 
 value x+1.


That is what really happens, but won't help understanding references. So 
  it is not useful for that purpose.

Andrei
Mar 23 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Bruno Medeiros wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Tue, 20 Mar 2007 16:01:35 -0700, Walter Bright wrote:



 A symbol is a name to which is 'bound' a value.


  ...


 Here, we bind a new value to the symbol x:
      x = 4;


 I used to use the verb 'to assign' for this concept. I guess that's 
 still
 okay or must I modernize <G>


 You may want to modernize. "Assign" doesn't quite catch the notion of 
 indirect reference, and from a couple of posts I understand that this 
 is a source of confusion.


 Huh, " "Assign" doesn't quite catch the notion of indirect reference", 
 what do you mean by that? I too was thinking that "assign" is a much 
 better term than "binding".


 A very useful way to see "int x = 4;" is that the symbol x is bound 
 to the Platonic number 4. The 4 itself cannot change. You can rebind 
 x by, say, writing ++x. That unbinds x from Plato 4 and binds it to 
 Plato 5. Once this is clear, the notions of values and references 
 clarifies a lot.


 Dear Gods. Yes, that conceptualization is correct, but again, how is 
 it any better than "assign"/"assignability"?

   A very useful way to see "int x = 4;" is that the symbol x is 
 assigned to the value 4. You can reassign x by writing ++x. That 
 assigns x to the value x+1.


 
 That is what really happens, but won't help understanding references. So 
  it is not useful for that purpose.
 
 Andrei


Yes, that you've said already, what I would like to know is why. :P
What's the issue with assign and references?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Derek Parnell wrote:

 'const' is a guarantee that any data of that type will never be modified 
 through a reference to that type (though other, non-const references to 
 that type can modify the data).


 
  const Foo f = new Foo("nice");
        Foo g = f;
 


Since the above case wasn't answered, I will. The "Foo g = f;" statement 
isn't allowed at all, because you are casting a const (think readonly) 
reference to a non-const reference. That isn't allowed, by design, since 
the very purpose of const (think readonly), is to disallow the holder of 
that reference to do any changes on the reference data.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:

 Bruno has answered your specific questions, so I'll take a more general 
 tack.
 
 A symbol is a name to which is 'bound' a value.
 
 static int x = 3;
 
 '3' is the value.
 'int' is the type.
 'x' is the symbol.
 'static' is the storage class.
 
 Here, we bind a new value to the symbol x:
     x = 4;
 
 A storage class originally meant where the symbol is stored, such as in 
 the data segment, on the stack, in a register, or in ROM. It's been 
 generalized a bit since then. The main way to tell a storage class apart 
 is that:
 1) a storage class applies to the symbol
 2) a type is independent of storage class, i.e. you cannot create a type 
 that is "pointer to static" or "array of extern". Storage classes do not 
 affect overloading, nor type deduction.
 
 'invariant' and 'const' are type modifiers (aka type constructors), 
 which mean when they are applied to a type, a new type is created that 
 is a combination.
 
 'invariant' is a guarantee that any data of that type will never change. 
 'const' is a guarantee that any data of that type will never be modified 
 through a reference to that type (though other, non-const references to 
 that type can modify the data).


So 'final' will be a storage class and not a type modifier? That's one 
of the questions I still have with regards to your design, because I'm 
not seeing how 'final' can also not-be a type modifier. In particular, 
again, what is
   typeof(&foo)
where foo is:
   final Foo foo;
?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bruno Medeiros wrote:

 Walter Bright wrote:

 Bruno has answered your specific questions, so I'll take a more
 general tack.

 A symbol is a name to which is 'bound' a value.

 static int x = 3;

 '3' is the value.
 'int' is the type.
 'x' is the symbol.
 'static' is the storage class.

 Here, we bind a new value to the symbol x:
     x = 4;

 A storage class originally meant where the symbol is stored, such as
 in the data segment, on the stack, in a register, or in ROM. It's been
 generalized a bit since then. The main way to tell a storage class
 apart is that:
 1) a storage class applies to the symbol
 2) a type is independent of storage class, i.e. you cannot create a
 type that is "pointer to static" or "array of extern". Storage classes
 do not affect overloading, nor type deduction.

 'invariant' and 'const' are type modifiers (aka type constructors),
 which mean when they are applied to a type, a new type is created that
 is a combination.

 'invariant' is a guarantee that any data of that type will never
 change. 'const' is a guarantee that any data of that type will never
 be modified through a reference to that type (though other, non-const
 references to that type can modify the data).


 
 So 'final' will be a storage class and not a type modifier? That's one
 of the questions I still have with regards to your design, because I'm
 not seeing how 'final' can also not-be a type modifier. In particular,
 again, what is
   typeof(&foo)
 where foo is:
   final Foo foo;
 ?


I imagine it would be (invariant Foo*): an invariant pointer to a
reference to a Foo.  Since *no one* is ever allowed to change final
storage, then a pointer to it must be invariant.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 23 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Daniel Keep wrote:

 
 Bruno Medeiros wrote:

 Walter Bright wrote:

 Bruno has answered your specific questions, so I'll take a more
 general tack.

 A symbol is a name to which is 'bound' a value.

 static int x = 3;

 '3' is the value.
 'int' is the type.
 'x' is the symbol.
 'static' is the storage class.

 Here, we bind a new value to the symbol x:
     x = 4;

 A storage class originally meant where the symbol is stored, such as
 in the data segment, on the stack, in a register, or in ROM. It's been
 generalized a bit since then. The main way to tell a storage class
 apart is that:
 1) a storage class applies to the symbol
 2) a type is independent of storage class, i.e. you cannot create a
 type that is "pointer to static" or "array of extern". Storage classes
 do not affect overloading, nor type deduction.

 'invariant' and 'const' are type modifiers (aka type constructors),
 which mean when they are applied to a type, a new type is created that
 is a combination.

 'invariant' is a guarantee that any data of that type will never
 change. 'const' is a guarantee that any data of that type will never
 be modified through a reference to that type (though other, non-const
 references to that type can modify the data).


 So 'final' will be a storage class and not a type modifier? That's one
 of the questions I still have with regards to your design, because I'm
 not seeing how 'final' can also not-be a type modifier. In particular,
 again, what is
   typeof(&foo)
 where foo is:
   final Foo foo;
 ?


 
 I imagine it would be (invariant Foo*): an invariant pointer to a
 reference to a Foo.  Since *no one* is ever allowed to change final
 storage, then a pointer to it must be invariant.
 
 	-- Daniel
 


No, that's not possible. It was mentioned before in another post:
news://news.digitalmars.com:119/etv81l$m94$1 digitalmars.com
Since invariant is (planned to be) transitive, then that typeof can't be 
(invariant Foo*), since the contents of foo can change (altough the 
immediate-value won't).


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 24 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bruno Medeiros wrote:

 Daniel Keep wrote:

 Bruno Medeiros wrote:

 Walter Bright wrote:

 Bruno has answered your specific questions, so I'll take a more
 general tack.

 A symbol is a name to which is 'bound' a value.

 static int x = 3;

 '3' is the value.
 'int' is the type.
 'x' is the symbol.
 'static' is the storage class.

 Here, we bind a new value to the symbol x:
     x = 4;

 A storage class originally meant where the symbol is stored, such as
 in the data segment, on the stack, in a register, or in ROM. It's been
 generalized a bit since then. The main way to tell a storage class
 apart is that:
 1) a storage class applies to the symbol
 2) a type is independent of storage class, i.e. you cannot create a
 type that is "pointer to static" or "array of extern". Storage classes
 do not affect overloading, nor type deduction.

 'invariant' and 'const' are type modifiers (aka type constructors),
 which mean when they are applied to a type, a new type is created that
 is a combination.

 'invariant' is a guarantee that any data of that type will never
 change. 'const' is a guarantee that any data of that type will never
 be modified through a reference to that type (though other, non-const
 references to that type can modify the data).


 So 'final' will be a storage class and not a type modifier? That's one
 of the questions I still have with regards to your design, because I'm
 not seeing how 'final' can also not-be a type modifier. In particular,
 again, what is
   typeof(&foo)
 where foo is:
   final Foo foo;
 ?


 I imagine it would be (invariant Foo*): an invariant pointer to a
 reference to a Foo.  Since *no one* is ever allowed to change final
 storage, then a pointer to it must be invariant.

     -- Daniel


 
 No, that's not possible. It was mentioned before in another post:
 news://news.digitalmars.com:119/etv81l$m94$1 digitalmars.com
 Since invariant is (planned to be) transitive, then that typeof can't be
 (invariant Foo*), since the contents of foo can change (altough the
 immediate-value won't).


You are, of course, right.  Damnit.  Just when I thought I understood
all this... :(

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 24 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 kris wrote:

 So, "invariant" is already a keyword ... what about that?


 I completely missed that one. I think it's a good idea to look into it 
 as a candidate for a qualifier name. Thank you.


 
 I agree. I think:
 
 final
 const
 invariant
 
 for the three cases looks pretty good.


Assuming that 'invariant' = really constant, 'const' = C++ pseudo-const...

It's better than super const. However:
(1) I would want to go through all my existing D code and change 100% of 
my usages of 'const' to 'invariant'.
(2) although (1) could be avoided with the rule that 'const' on a 
declaration implicitly means 'invariant', this would then mean that to 
match a 'const' value, you use 'invariant'; but to match a non-const 
value, you use 'const'. That's horribly confusing.
(3) I concede the problem of association with 'readonly' and ROM. But 
the association between 'const' and 'constant' is pretty strong.

The problem remains that in:

const int a = 2;

void f(const int b)
{

}

a really is a constant, but there is nothing constant about 'b'!

How about 'protected'?
It seems to cover the 'don't touch' meaning pretty well...
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Don Clugston wrote:

 Assuming that 'invariant' = really constant, 'const' = C++ pseudo-const...


Yah.


 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% of 
 my usages of 'const' to 'invariant'.


Great to hear that!


 (2) although (1) could be avoided with the rule that 'const' on a 
 declaration implicitly means 'invariant', this would then mean that to 
 match a 'const' value, you use 'invariant'; but to match a non-const 
 value, you use 'const'. That's horribly confusing.


This I don't understand. Could you give an example?


 (3) I concede the problem of association with 'readonly' and ROM. But 
 the association between 'const' and 'constant' is pretty strong.


I think there's universal agreement that you can't express tersely the 
two notions "const-as-in-C++" and "const-as-in-we-really-mean-it". 
Probably it's best to just go with two terms and move on.


 The problem remains that in:
 
 const int a = 2;
 
 void f(const int b)
 {
 
 }
 
 a really is a constant, but there is nothing constant about 'b'!


The code is incorrect. Const and invariant refer to indirectly-addressed 
memory. Probably you mean:

final int a = 2;

void f(final int b)
{
}

The choice of "final" in the first case makes "a" bound to "2" for 
eternity. The choice of "final" in the second case prevents f from 
changing its argument, and it's the free will choice of f's author. The 
"final" does not influence f's signature or how other people use it. 
It's just constraining f's implementation.

The two uses of "final" are reasonably consistent with one another.


 How about 'protected'?
 It seems to cover the 'don't touch' meaning pretty well...


class Foo {
   protected: protected char[] find(protected char[] haystack, protected 
char[] needle);
}

'Nuff said :o).


Andrei
Mar 19 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% 
 of my usages of 'const' to 'invariant'.


 
 Great to hear that!


I think one of us misunderstood.
I parsed that sentence as "I'd have to go through all my D code to keep 
it working properly", while judging by your reaction you seem to have 
parsed it as "I'd be happy to go through all my D code and make the 
necessary changes".
(Note that the connotation(?) is a bit different; neutral/slightly 
negative vs quite positive)
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Frits van Bommel wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% 
 of my usages of 'const' to 'invariant'.


 Great to hear that!


 
 I think one of us misunderstood.
 I parsed that sentence as "I'd have to go through all my D code to keep 
 it working properly", while judging by your reaction you seem to have 
 parsed it as "I'd be happy to go through all my D code and make the 
 necessary changes".
 (Note that the connotation(?) is a bit different; neutral/slightly 
 negative vs quite positive)


Well, I looked up "want" in my dictionary and parsed the sentence 
accordingly :o).

Andrei
Mar 19 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Frits van Bommel wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 
 100% of my usages of 'const' to 'invariant'.


 Great to hear that!


 I think one of us misunderstood.
 I parsed that sentence as "I'd have to go through all my D code to 
 keep it working properly", while judging by your reaction you seem to 
 have parsed it as "I'd be happy to go through all my D code and make 
 the necessary changes".
 (Note that the connotation(?) is a bit different; neutral/slightly 
 negative vs quite positive)


 
 Well, I looked up "want" in my dictionary and parsed the sentence 
 accordingly :o).


Did you look up "would" as well? :P
I read that to mean "if this was changed ..."
Mar 19 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 Assuming that 'invariant' = really constant, 'const' = C++ 
 pseudo-const...


 
 Yah.
 

 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% 
 of my usages of 'const' to 'invariant'.


 
 Great to hear that!


Great perhaps, but it does suggest that 'const' should perhaps be the 
signifier for what 'invariant' has been proposed for (the literal 
meaning of each term notwithstanding)?


 (2) although (1) could be avoided with the rule that 'const' on a 
 declaration implicitly means 'invariant', this would then mean that to 
 match a 'const' value, you use 'invariant'; but to match a non-const 
 value, you use 'const'. That's horribly confusing.


 
 This I don't understand. Could you give an example?


invariant int* x;
int* y;

void fn( const int* z ) {}

fn( x );
fn( y );

Assuming the above is legal, 'const' is the qualifier which binds to all 
reference types, ie. "to match a non-const value, you use 'const'."


 (3) I concede the problem of association with 'readonly' and ROM. But 
 the association between 'const' and 'constant' is pretty strong.


 
 I think there's universal agreement that you can't express tersely the 
 two notions "const-as-in-C++" and "const-as-in-we-really-mean-it". 
 Probably it's best to just go with two terms and move on.
 

 The problem remains that in:

 const int a = 2;

 void f(const int b)
 {

 }

 a really is a constant, but there is nothing constant about 'b'!


 
 The code is incorrect. Const and invariant refer to indirectly-addressed 
 memory. Probably you mean:
 
 final int a = 2;
 
 void f(final int b)
 {
 }
 
 The choice of "final" in the first case makes "a" bound to "2" for 
 eternity. The choice of "final" in the second case prevents f from 
 changing its argument, and it's the free will choice of f's author. The 
 "final" does not influence f's signature or how other people use it. 
 It's just constraining f's implementation.
 
 The two uses of "final" are reasonably consistent with one another.
 

 How about 'protected'?
 It seems to cover the 'don't touch' meaning pretty well...


 
 class Foo {
   protected: protected char[] find(protected char[] haystack, protected 
 char[] needle);
 }
 
 'Nuff said :o).


It's too bad too, since this word makes the most semantic sense :-)


Sean
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 Assuming that 'invariant' = really constant, 'const' = C++ 
 pseudo-const...


 Yah.


 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% 
 of my usages of 'const' to 'invariant'.


 Great to hear that!


 
 Great perhaps, but it does suggest that 'const' should perhaps be the 
 signifier for what 'invariant' has been proposed for (the literal 
 meaning of each term notwithstanding)?


No. There will be far more uses for const than for invariant. You can 
take my word for that.


 (2) although (1) could be avoided with the rule that 'const' on a 
 declaration implicitly means 'invariant', this would then mean that 
 to match a 'const' value, you use 'invariant'; but to match a 
 non-const value, you use 'const'. That's horribly confusing.


 This I don't understand. Could you give an example?


 
 invariant int* x;
 int* y;
 
 void fn( const int* z ) {}
 
 fn( x );
 fn( y );
 
 Assuming the above is legal, 'const' is the qualifier which binds to all 
 reference types, ie. "to match a non-const value, you use 'const'."


That is correct.


Andrei
Mar 19 2007
parent reply kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:
 

 Andrei Alexandrescu (See Website For Email) wrote:


 Don Clugston wrote:


 Assuming that 'invariant' = really constant, 'const' = C++ 
 pseudo-const...



 Yah.


 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 
 100% of my usages of 'const' to 'invariant'.



 Great to hear that!



 Great perhaps, but it does suggest that 'const' should perhaps be the 
 signifier for what 'invariant' has been proposed for (the literal 
 meaning of each term notwithstanding)?


 
 
 No. There will be far more uses for const than for invariant. You can 
 take my word for that.
 

 (2) although (1) could be avoided with the rule that 'const' on a 
 declaration implicitly means 'invariant', this would then mean that 
 to match a 'const' value, you use 'invariant'; but to match a 
 non-const value, you use 'const'. That's horribly confusing.



 This I don't understand. Could you give an example?



 invariant int* x;
 int* y;

 void fn( const int* z ) {}

 fn( x );
 fn( y );

 Assuming the above is legal, 'const' is the qualifier which binds to 
 all reference types, ie. "to match a non-const value, you use 'const'."


 
 
 That is correct.



How about some further example? Given these sigs:

struct Foo
{
    int a;
}

class Bar
{
    char[] b;
}

void fooish (inout Foo foo) {}

char[] barish (Bar bar) {return bar.b;}


1) how do I modify the function decls to have the compiler *enforce* 
readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be 
mutated within the function body?

2) how does the fooish() decl change to have the compiler *enforce* a 
readonly-view of the returned bar.b?

3) where fooish() has a Foo* rather than an inout Foo, is there any 


- Kris
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
(Reposted after cleanup :o))

kris wrote:

 How about some further example? Given these sigs:
 
 struct Foo
 {
    int a;
 }
 
 class Bar
 {
    char[] b;
 }
 
 void fooish (inout Foo foo) {}
 
 char[] barish (Bar bar) {return bar.b;}
 
 
 1) how do I modify the function decls to have the compiler *enforce* 
 readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be 
 mutated within the function body?


void fooish (const ref Foo foo) {}

char[] barish (const Bar bar) {return bar.b;}


 2) how does the fooish() decl change to have the compiler *enforce* a 
 readonly-view of the returned bar.b?


const char[] barish (const Bar bar) {return bar.b;}


 3) where fooish() has a Foo* rather than an inout Foo, is there any 



void fooish (const Foo* foo) {}

By the way, a couple of days ago I've had an idea. Many people here ask
for a "string" alias because char[] is a tad hard to type and uneasy on
the eyes. Probably a good candidate would be:

alias invariant char[] string;

The resulting type is pretty damn slick:

1. You can alias it and slice it til you get blue in the face - no
confusion ever, because nobody can overwrite the contents underneath
your alias.

2. The EnsureCString(ref string) function will reallocate and copy the
string at most once and only for a slice, never for the "original"
string which was zero-terminated during construction.

3. The ~= operator works (somewhat surprisingly).

4. It's very, very rare that you want to modify some random character in
a string, and when you do, use a char[] and then copy it back into a
string, or rebuild the string from slices!

5. The Java experience (where String is immutable and StringBuffer is
the mutable, build-me-piecemeal object) turned out to be largely
successful, modulo syntax details that are not so elegant.

6. It meshes great with literals, which are exactly invariant arrays of
characters:

string hi = "Hello!"; // no dup needed! And it's 100% safe!

So it looks like we have solved the string issue in an unexpectedly
elegant way - by simply combining two features: invariant and array.


Andrei
Mar 19 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 
 By the way, a couple of days ago I've had an idea. Many people here ask
 for a "string" alias because char[] is a tad hard to type and uneasy on
 the eyes. Probably a good candidate would be:
 
 alias invariant char[] string;
 
 The resulting type is pretty damn slick:


...

 3. The ~= operator works (somewhat surprisingly).


I assume this is because a char[] is actually a struct containing a 
pointer, so 'invariant' allows that pointer to be reassigned--it simply 
protects the referenced string?  This is the sticking point for me. 
Assume we have this:

     struct Foo
     {
         int  x;
         int* y;
     }

     const Foo foo; // is this legal?
     foo.x  = 1;    // this is allowed
     *foo.y = 2;    // this is not allowed

Is that correct, or do 'const' and 'invariant' truly only apply to pure 
reference types?


 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!


This may be true for a string, but for arrays in general I think this is 
fairly common.


 5. The Java experience (where String is immutable and StringBuffer is
 the mutable, build-me-piecemeal object) turned out to be largely
 successful, modulo syntax details that are not so elegant.
 
 6. It meshes great with literals, which are exactly invariant arrays of
 characters:
 
 string hi = "Hello!"; // no dup needed! And it's 100% safe!
 
 So it looks like we have solved the string issue in an unexpectedly
 elegant way - by simply combining two features: invariant and array.


Agreed.  This is pretty nice :-)


Sean
Mar 19 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 By the way, a couple of days ago I've had an idea. Many people here ask
 for a "string" alias because char[] is a tad hard to type and uneasy on
 the eyes. Probably a good candidate would be:

 alias invariant char[] string;

 The resulting type is pretty damn slick:


 ...

 3. The ~= operator works (somewhat surprisingly).


 
 I assume this is because a char[] is actually a struct containing a 
 pointer, so 'invariant' allows that pointer to be reassigned--it simply 
 protects the referenced string?  This is the sticking point for me. 


That is correct. For an understanding of a ~= b, think of it as a = a ~ 
b. Do I modify the stuff indirectly referenced by "a"? No, Sir. I just 
rebind a to a larger entity that embeds a copy of its former self.

In practice, the concatenation will not always produce a copy. The 
implementation will work "as if" you always produce a copy.


 Assume we have this:
 
     struct Foo
     {
         int  x;
         int* y;
     }
 
     const Foo foo; // is this legal?


Yes.


     foo.x  = 1;    // this is allowed


Yes.


     *foo.y = 2;    // this is not allowed


It's not allowed.


 Is that correct, or do 'const' and 'invariant' truly only apply to pure 
 reference types?


No. They apply to any type that embeds references.

"final" applies to all types and guards the bits of the symbol itself. 
"final const" guards symbol bits + referenced bits, and "final 
invariant" is as opposed to change as the 19th century British education 
system. (Did I get that right?)


 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!


 
 This may be true for a string, but for arrays in general I think this is 
 fairly common.


Yes. That's why arrays will stay in place :o).


Andrei
Mar 19 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 (Reposted after cleanup :o))
 
 kris wrote:

 How about some further example? Given these sigs:

 struct Foo
 {
    int a;
 }

 class Bar
 {
    char[] b;
 }

 void fooish (inout Foo foo) {}

 char[] barish (Bar bar) {return bar.b;}


 1) how do I modify the function decls to have the compiler *enforce*
 readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be
 mutated within the function body?


 
 void fooish (const ref Foo foo) {}
 
 char[] barish (const Bar bar) {return bar.b;}
 

 2) how does the fooish() decl change to have the compiler *enforce* a
 readonly-view of the returned bar.b?


 
 const char[] barish (const Bar bar) {return bar.b;}


Hang on... wouldn't that need to be the signature of barish in the first
place?  If const is transitive, bar is declared as a const Bar and
you're returning bar.b, isn't bar.b const as well?


 3) where fooish() has a Foo* rather than an inout Foo, is there any



 
 void fooish (const Foo* foo) {}
 
 By the way, a couple of days ago I've had an idea. Many people here ask
 for a "string" alias because char[] is a tad hard to type and uneasy on
 the eyes. Probably a good candidate would be:
 
 alias invariant char[] string;
 
 The resulting type is pretty damn slick:
 
 1. You can alias it and slice it til you get blue in the face - no
 confusion ever, because nobody can overwrite the contents underneath
 your alias.
 
 2. The EnsureCString(ref string) function will reallocate and copy the
 string at most once and only for a slice, never for the "original"
 string which was zero-terminated during construction.
 
 3. The ~= operator works (somewhat surprisingly).
 
 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!
 
 5. The Java experience (where String is immutable and StringBuffer is
 the mutable, build-me-piecemeal object) turned out to be largely
 successful, modulo syntax details that are not so elegant.
 
 6. It meshes great with literals, which are exactly invariant arrays of
 characters:
 
 string hi = "Hello!"; // no dup needed! And it's 100% safe!
 
 So it looks like we have solved the string issue in an unexpectedly
 elegant way - by simply combining two features: invariant and array.
 
 
 Andrei


You're a cruel, cruel man, Andrei.  Now we're going to have to wait
patiently for this... :'(

Seriously, though, this is cool stuff.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 19 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:

 
 Andrei Alexandrescu (See Website For Email) wrote:

 (Reposted after cleanup :o))

 kris wrote:

 How about some further example? Given these sigs:

 struct Foo
 {
    int a;
 }

 class Bar
 {
    char[] b;
 }

 void fooish (inout Foo foo) {}

 char[] barish (Bar bar) {return bar.b;}


 1) how do I modify the function decls to have the compiler *enforce*
 readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be
 mutated within the function body?


 void fooish (const ref Foo foo) {}

 char[] barish (const Bar bar) {return bar.b;}


 2) how does the fooish() decl change to have the compiler *enforce* a
 readonly-view of the returned bar.b?


 const char[] barish (const Bar bar) {return bar.b;}


 
 Hang on... wouldn't that need to be the signature of barish in the first
 place?  If const is transitive, bar is declared as a const Bar and
 you're returning bar.b, isn't bar.b const as well?


"Nobody said all examples must compile" -- Andrei

:o)

Andrei
Mar 19 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 (Reposted after cleanup :o))
 
 kris wrote:
 

 How about some further example? Given these sigs:

 struct Foo
 {
    int a;
 }

 class Bar
 {
    char[] b;
 }

 void fooish (inout Foo foo) {}

 char[] barish (Bar bar) {return bar.b;}


 1) how do I modify the function decls to have the compiler *enforce* 
 readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be 
 mutated within the function body?


 
 
 void fooish (const ref Foo foo) {}
 
 char[] barish (const Bar bar) {return bar.b;}
 

 2) how does the fooish() decl change to have the compiler *enforce* a 
 readonly-view of the returned bar.b?


 
 
 const char[] barish (const Bar bar) {return bar.b;}
 

 3) where fooish() has a Foo* rather than an inout Foo, is there any 



 
 
 void fooish (const Foo* foo) {}
 



would seem that the above answer permits an escaping mutable ref. I 
imagine that's not covered in the *cough* scope of the const domain 
since it can be sidestepped easily?



 By the way, a couple of days ago I've had an idea. Many people here ask
 for a "string" alias because char[] is a tad hard to type and uneasy on
 the eyes. Probably a good candidate would be:
 
 alias invariant char[] string;
 
 The resulting type is pretty damn slick:
 
 1. You can alias it and slice it til you get blue in the face - no
 confusion ever, because nobody can overwrite the contents underneath
 your alias.
 
 2. The EnsureCString(ref string) function will reallocate and copy the
 string at most once and only for a slice, never for the "original"
 string which was zero-terminated during construction.
 
 3. The ~= operator works (somewhat surprisingly).
 
 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!
 
 5. The Java experience (where String is immutable and StringBuffer is
 the mutable, build-me-piecemeal object) turned out to be largely
 successful, modulo syntax details that are not so elegant.
 
 6. It meshes great with literals, which are exactly invariant arrays of
 characters:
 
 string hi = "Hello!"; // no dup needed! And it's 100% safe!
 
 So it looks like we have solved the string issue in an unexpectedly
 elegant way - by simply combining two features: invariant and array.



These are some of the reasons why a handful of us have been bitchin' 
about immutable views for so long.

Regarding the alias, you'd likely have to consider w/dchar variations 
also ... it becomes a bit messy as things progress, which is one of the 
reasons we never had a string alias in the first place -- at least now 
there's more weight to the argument for an alias
Mar 19 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
kris wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 (Reposted after cleanup :o))

 kris wrote:


 How about some further example? Given these sigs:

 struct Foo
 {
    int a;
 }

 class Bar
 {
    char[] b;
 }

 void fooish (inout Foo foo) {}

 char[] barish (Bar bar) {return bar.b;}


 1) how do I modify the function decls to have the compiler *enforce* 
 readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be 
 mutated within the function body?



 void fooish (const ref Foo foo) {}

 char[] barish (const Bar bar) {return bar.b;}


 2) how does the fooish() decl change to have the compiler *enforce* a 
 readonly-view of the returned bar.b?



 const char[] barish (const Bar bar) {return bar.b;}


 3) where fooish() has a Foo* rather than an inout Foo, is there any 




 void fooish (const Foo* foo) {}


 

 would seem that the above answer permits an escaping mutable ref. I 
 imagine that's not covered in the *cough* scope of the const domain 
 since it can be sidestepped easily?


Nobody said all examples must compile :o). In short, you won't be able 
to go const -> ~const without a cast, and the cast is never defined to 
harbor defined behavior.


 By the way, a couple of days ago I've had an idea. Many people here ask
 for a "string" alias because char[] is a tad hard to type and uneasy on
 the eyes. Probably a good candidate would be:

 alias invariant char[] string;

 The resulting type is pretty damn slick:

 1. You can alias it and slice it til you get blue in the face - no
 confusion ever, because nobody can overwrite the contents underneath
 your alias.

 2. The EnsureCString(ref string) function will reallocate and copy the
 string at most once and only for a slice, never for the "original"
 string which was zero-terminated during construction.

 3. The ~= operator works (somewhat surprisingly).

 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!

 5. The Java experience (where String is immutable and StringBuffer is
 the mutable, build-me-piecemeal object) turned out to be largely
 successful, modulo syntax details that are not so elegant.

 6. It meshes great with literals, which are exactly invariant arrays of
 characters:

 string hi = "Hello!"; // no dup needed! And it's 100% safe!

 So it looks like we have solved the string issue in an unexpectedly
 elegant way - by simply combining two features: invariant and array.


 
 
 These are some of the reasons why a handful of us have been bitchin' 
 about immutable views for so long.
 
 Regarding the alias, you'd likely have to consider w/dchar variations 
 also ... it becomes a bit messy as things progress, which is one of the 
 reasons we never had a string alias in the first place -- at least now 
 there's more weight to the argument for an alias


Yah. Probably the aliases will come as a troika, string, wstring, and 
dstring (for lack of more inspired names).


Andrei
Mar 19 2007
prev sibling next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


I wish it wasn't so hard to get a simple straight answer from the experts.

So far I think /The W&A Show/ is saying that 'const' and 'invariant' only
apply to reference data types (objects, variable-length arrays, and
pointers) and structs. They do not apply *in any way, shape or form* to any
other data type.

  const char[] s;    // ok
  const char   c;    // meaningless, the 'const' is ignored.
  const classFoo f;  // okay
  const double* b;   // okay;
  const double  d;   // meaningless, the 'const' is ignored.
  const structBar q; // okay

'const' means you cannot change the stuff the reference is referencing or
the members of the struct, *but* for reference types you can change the
reference value.

  s[0] = 'a'; // fails
  s    = "new data"; //ok
  s.length = 2; // ok

  c    = 'a'; // ok

  f.bar = 'a'; // fails
  f = new classFoo(); // okay

  *b    = 1.0; // fails
  b     = &someDouble; // ok

  d     = 1.0; // okay

  q.foo = 'a'; // fails

'invariant' means you cannot change the stuff the reference is referencing
or the members of the struct, *and* for reference types you cannot change
the reference value.

 (If you one used 'invariant' rather than 'const' in above declarations...)
  s[0] = 'a'; // fails
  s    = "new data"; // fails
  s.length = 2; // fails

  c    = 'a'; // ok

  f.bar = 'a'; // fails
  f = new classFoo(); // fails

  *b    = 1.0; // fails
  b     = &someDouble; // fails

  d     = 1.0; // okay

  q.foo = 'a'; // fails


However, if this is the interpretation of 'invariant', how does one ever
get to set the 'invariant' thing's value?

   invariant byte[] vCodes;
   . . . 
   vCodes = LoadCodesFromFile();  // fails, no???



 By the way, a couple of days ago I've had an idea. Many people here ask
 for a "string" alias because char[] is a tad hard to type and uneasy on
 the eyes. Probably a good candidate would be:
 
 alias invariant char[] string;

 The resulting type is pretty damn slick:
 
 1. You can alias it and slice it til you get blue in the face - no
 confusion ever, because nobody can overwrite the contents underneath
 your alias.


 void func( string s )
 {

     string t;
     char[] u;
     u = s;
     u[0] = 'a'; // fails.
     u = s[1..4];
     u[0] = 'a'; // fails
     u = s.dup;
     u[0] = 'a' // ok

     t = s; // fails???

 }
  


 3. The ~= operator works (somewhat surprisingly).


 void func( string s )
 {
     string t;
     char[] u;

     u ~= s; // ok
     s ~= 'a'; // fails ???

     t ~= s; // fails???
 }

    

 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!


It is not so rare in the type of applications that I do. 

Are you saying that I can do this...?

 string func( string s )
 {
     char[] u;
     u = s.dup;
     u[somerandomspot] = 'a';
     return u;
 }
  
or this ... ?

 void func( string ref s )
 {
     char[] u;
     u = s.dup;
     u[somerandomspot] = 'a';
     s = u;
 }

or this ... ?

 string func( string ref s )
 {
     char[] u;
     string t;
     u = s.dup;
     u[somerandomspot] = 'a';
     t = u;
 }

What I don't get here is the phrase "copy it back into a string". This
sounds ambiguous to me. It could mean, "construct a new string containing
the updated data", or "replace the original string reference with a
reference to the updated data". But I was starting to think that
'invariant' meant that you couldn't change the reference value at all, so I
don't see how one could change an 'invariant' parameter or construct an
'invariant' local /variable/.

 

 So it looks like we have solved the string issue in an unexpectedly
 elegant way - by simply combining two features: invariant and array.


I hope so.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
20/03/2007 9:28:14 AM
Mar 19 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 I wish it wasn't so hard to get a simple straight answer from the experts.


It's not like anybody tries to obfuscate their writing.


 So far I think /The W&A Show/ is saying that 'const' and 'invariant' only
 apply to reference data types (objects, variable-length arrays, and
 pointers) and structs. They do not apply *in any way, shape or form* to any
 other data type.
 
   const char[] s;    // ok
   const char   c;    // meaningless, the 'const' is ignored.
   const classFoo f;  // okay
   const double* b;   // okay;
   const double  d;   // meaningless, the 'const' is ignored.
   const structBar q; // okay
 
 'const' means you cannot change the stuff the reference is referencing or
 the members of the struct, *but* for reference types you can change the
 reference value.
 
   s[0] = 'a'; // fails
   s    = "new data"; //ok
   s.length = 2; // ok
 
   c    = 'a'; // ok
 
   f.bar = 'a'; // fails
   f = new classFoo(); // okay
 
   *b    = 1.0; // fails
   b     = &someDouble; // ok
 
   d     = 1.0; // okay
 
   q.foo = 'a'; // fails


Correct.


 'invariant' means you cannot change the stuff the reference is referencing
 or the members of the struct, *and* for reference types you cannot change
 the reference value.


No. Invariant means that the data referenced indirectly is never 
modifiable by any part of the program.

What you called 'invariant' above is 'final const'.

[snip]

 However, if this is the interpretation of 'invariant', how does one ever
 get to set the 'invariant' thing's value?
 
    invariant byte[] vCodes;
    . . . 
    vCodes = LoadCodesFromFile();  // fails, no???


Right now you can only initialize invariant with literals. This aspect 
of the language is still under development. (Things like the result of 
some_string.dup also come to mind.)


  void func( string s )
  {
 
      string t;
      char[] u;
      u = s;
      u[0] = 'a'; // fails.
      u = s[1..4];
      u[0] = 'a'; // fails
      u = s.dup;
      u[0] = 'a' // ok
 
      t = s; // fails???
 
  }


You can't make the assignment u = s.


 3. The ~= operator works (somewhat surprisingly).


  void func( string s )
  {
      string t;
      char[] u;
 
      u ~= s; // ok
      s ~= 'a'; // fails ???
 
      t ~= s; // fails???
  }


s ~= a; works and is equivalent to s = s ~ a, i.e. "rebind s to the 
concatenation of s and a". It's an operation that does not mutate s's 
contents.


 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!


 
 It is not so rare in the type of applications that I do. 


You use char[] for that, and when you are done modifying, you can put 
things in a string.


 Are you saying that I can do this...?
 
  string func( string s )
  {
      char[] u;
      u = s.dup;
      u[somerandomspot] = 'a';
      return u;
  }


This is sound, but tricky to typecheck. I'll have to get back to you on 
that one.


 or this ... ?
 
  void func( string ref s )
  {
      char[] u;
      u = s.dup;
      u[somerandomspot] = 'a';
      s = u;
  }


Same as above.


 or this ... ?
 
  string func( string ref s )
  {
      char[] u;
      string t;
      u = s.dup;
      u[somerandomspot] = 'a';
      t = u;
  }


These last three examples work because u is temporary and not aliased 
with anything. If it were, the code would be unsound. Such cases are 
tricky to typecheck in the general case, but we'll look into a solution 
that allows such expressive idioms without also taking risks.


 What I don't get here is the phrase "copy it back into a string". This
 sounds ambiguous to me. It could mean, "construct a new string containing
 the updated data", or "replace the original string reference with a
 reference to the updated data". But I was starting to think that
 'invariant' meant that you couldn't change the reference value at all, so I
 don't see how one could change an 'invariant' parameter or construct an
 'invariant' local /variable/.


Indeed, 'invariant' meant that the referenced data is invariant. The 
actual variable can be rebound to any other invariant data. It's like 
watching TV: you can always change your choice of watching, but you 
can't modify the actual contents of programs - unless you take special 
measures :o).


Andrei
Mar 19 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 19 Mar 2007 16:20:04 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Derek Parnell wrote:

 I wish it wasn't so hard to get a simple straight answer from the experts.


 
 It's not like anybody tries to obfuscate their writing.


LOL ... I realize that. Some people are just naturals at it.


 So far I think /The W&A Show/ is saying that 'const' and 'invariant' only
 apply to reference data types (objects, variable-length arrays, and
 pointers) and structs. They do not apply *in any way, shape or form* to any
 other data type.
 
   const char[] s;    // ok
   const char   c;    // meaningless, the 'const' is ignored.
   const classFoo f;  // okay
   const double* b;   // okay;
   const double  d;   // meaningless, the 'const' is ignored.
   const structBar q; // okay
 
 'const' means you cannot change the stuff the reference is referencing or
 the members of the struct, *but* for reference types you can change the
 reference value.
 
   s[0] = 'a'; // fails
   s    = "new data"; //ok
   s.length = 2; // ok
 
   c    = 'a'; // ok
 
   f.bar = 'a'; // fails
   f = new classFoo(); // okay
 
   *b    = 1.0; // fails
   b     = &someDouble; // ok
 
   d     = 1.0; // okay
 
   q.foo = 'a'; // fails


 
 Correct.



YAY!!!! Finally something has sunk in to my head <G>
 

 'invariant' means you cannot change the stuff the reference is referencing
 or the members of the struct, *and* for reference types you cannot change
 the reference value.


 
 No. Invariant means that the data referenced indirectly is never 
 modifiable by any part of the program.
 
 What you called 'invariant' above is 'final const'.


Hmmm ... so the difference between 'const' and 'invariant' is that const is
only effective for one level deep, but 'invariant' is effective for all
levels, right?

  struct Foo
  {
      int a;
      int* b;
      Foo c;
      Foo* d;
  }

  const Foo f_const;
  invariant Foo f_invar;
  int x;

  // assuming we can initialize f_const and f_invar at run time somehow,
  // then are the following subsequent assignments as stated?
  f_const.a = 1;       // fails
  f_const.b = &x;      // fails
  *f_const.b = 1;      // okay;
  f_const.c.a = 1;     // okay
  f_const.c.b = &x;    // okay
  *f_const.c.b = 1;    // okay
  f_const.d = new Foo; // fails
  f_const.d.a = 1;     // okay
  f_const.d.b = &x;    // okay
  *f_const.d.b = 1;    // okay

  f_invar.a = 1;       // fails
  f_invar.b = &x;      // fails
  *f_invar.b = 1;      // fails;
  f_invar.c.a = 1;     // fails
  f_invar.c.b = &x;    // fails
  *f_invar.c.b = 1;    // fails
  f_invar.d = new Foo; // fails
  f_invar.d.a = 1;     // fails
  f_invar.d.b = &x;    // fails
  *f_invar.d.b = 1;    // fails



 [snip]

 However, if this is the interpretation of 'invariant', how does one ever
 get to set the 'invariant' thing's value?
 
    invariant byte[] vCodes;
    . . . 
    vCodes = LoadCodesFromFile();  // fails, no???


 
 Right now you can only initialize invariant with literals. This aspect 
 of the language is still under development. (Things like the result of 
 some_string.dup also come to mind.)


Oh ... okay. I'll wait for that mind bender then.


  void func( string s )
  {
      char[] u;
      u = s;


 
 You can't make the assignment u = s.


Oh, okay. The compiler will stop at "u = s;" because that would have made
access to 's' data via the 'u' symbol. Got it.
 

 3. The ~= operator works (somewhat surprisingly).


  void func( string s )
  {
      string t;
      char[] u;
 
      u ~= s; // ok
      s ~= 'a'; // fails ???
 
      t ~= s; // fails???
  }


 
 s ~= a; works and is equivalent to s = s ~ a, i.e. "rebind s to the 
 concatenation of s and a". It's an operation that does not mutate s's 
 contents.


So, could this be the mechanism to set an invariant array?

   invariant ubyte[] b;
   b ~= Load_Stuff_From_File();


 4. It's very, very rare that you want to modify some random character in
 a string, and when you do, use a char[] and then copy it back into a
 string, or rebuild the string from slices!


 
 It is not so rare in the type of applications that I do. 


 
 You use char[] for that, and when you are done modifying, you can put 
 things in a string.


Oops. I was using "string" in the normal sense and not your new alias idea.
In the context of the alias 'string' then what you say makes a lot of
sense.


 It's like watching TV: you can always change your choice of watching


(Not if my wife has the remote <G>)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
20/03/2007 10:53:00 AM
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 Hmmm ... so the difference between 'const' and 'invariant' is that const is
 only effective for one level deep, but 'invariant' is effective for all
 levels, right?


Nonono. Const means: it might have originated as a variable, and 
somebody, somewhere, might hold a mutating reference to this and call it 
"my precious".

Invariant is: nobody ever holds a mutating reference to it.

Example:

void Fun(const char[] a, char[] b)
{
   char c = a[0];
   b[0] = 'z';
   assert(a[0] == c); // will fail
}

void main()
{
   char[] x = "Wyda".dup;
   Fun(x, x);
}

Notice how the data referenced to by a is changing from under a's feet. 
Now let's rewrite Fun:

void Gun(invariant char[] a, char[] b)
{
   char c = a[0];
   b[0] = 'z';
   assert(a[0] == c); // never, ever, ever, ever fails
}

void main()
{
   char[] x = "Wyda".dup;
   Fun(x, x); // can't compile!
       // mutating references can't be bound to invariant references
}


Andrei
Mar 19 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 19 Mar 2007 17:50:28 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Derek Parnell wrote:

 Hmmm ... so the difference between 'const' and 'invariant' is that const is
 only effective for one level deep, but 'invariant' is effective for all
 levels, right?


 
 Nonono. Const means: it might have originated as a variable, and 
 somebody, somewhere, might hold a mutating reference to this and call it 
 "my precious".
 
 Invariant is: nobody ever holds a mutating reference to it.


Yeah ... but that's not what I was talking about. But be that as it may, it
seems you are saying that the *only* difference between 'const' and
'invariant' is that 'invariant' means that every write attempt (direct and
indirect) is denied, but 'const' only prevents direct write attempts.

By 'direct' I mean explicitly using the symbol in the statement, and not
another symbol that happens to contain the same address of the data.


But I was talking earlier about the situation where something contains
reference types or structs, and what effect 'const' and 'invariant' have on
the things indirectly accessible via member data.

 struct Foo
 {
    char[] s;
 }

 void Func(const Foo fc, invariant Foo fi)
 {
    fc.s = "abc"; // fails ???
    fc.s[0] = 'a'; // okay ???

    fi.s = "abc"; // fails ???
    fi.s[0] = 'a'; // fails ???
 }

 Foo a;
 Foo b;
 Func(a,b); // fails ???

 const Foo ac;
 const Foo bc;
 Func(ac,bc); // fails ???

 invariant Foo ai;
 invariant Foo bi;
 Func(ai,bi); // fails ???

 Func(ac,bi); // okay ???


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
20/03/2007 12:04:01 PM
Mar 19 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 19 Mar 2007 17:50:28 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 

 Derek Parnell wrote:

 Hmmm ... so the difference between 'const' and 'invariant' is that const is
 only effective for one level deep, but 'invariant' is effective for all
 levels, right?


 Nonono. Const means: it might have originated as a variable, and 
 somebody, somewhere, might hold a mutating reference to this and call it 
 "my precious".

 Invariant is: nobody ever holds a mutating reference to it.


 
 Yeah ... but that's not what I was talking about. But be that as it may, it
 seems you are saying that the *only* difference between 'const' and
 'invariant' is that 'invariant' means that every write attempt (direct and
 indirect) is denied, but 'const' only prevents direct write attempts.
 
 By 'direct' I mean explicitly using the symbol in the statement, and not
 another symbol that happens to contain the same address of the data.
 
 
 But I was talking earlier about the situation where something contains
 reference types or structs, and what effect 'const' and 'invariant' have on
 the things indirectly accessible via member data.
 
  struct Foo
  {
     char[] s;
  }
 
  void Func(const Foo fc, invariant Foo fi)
  {
     fc.s = "abc"; // fails ???


Works. Understand that fc is the private copy owned by Func.


     fc.s[0] = 'a'; // okay ???


Fails. fc would change bits not belonging to itself, and "const" makes 
those bits unchangeable.


     fi.s = "abc"; // fails ???


Works. Modifies Func's own private copy of fi.


     fi.s[0] = 'a'; // fails ???


Fails.


  }
 
  Foo a;
  Foo b;
  Func(a,b); // fails ???


Fails. Can't bind modifiable b to an invariant Foo.


  const Foo ac;
  const Foo bc;
  Func(ac,bc); // fails ???


Fails. Can't bind const b (which conservatively may be aliased to a 
modifiable view) to an invariant Foo.


  invariant Foo ai;
  invariant Foo bi;
  Func(ai,bi); // fails ???


Works. No problem to bind ai to a const Foo.


  Func(ac,bi); // okay ???


Perfect.


Andrei
Mar 19 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Derek Parnell wrote:

 On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 
 
 I wish it wasn't so hard to get a simple straight answer from the experts.


I think discussion would much improved if big changes like this actually 
came with a detailed proposal on a website somewhere that people could 
refer to and which would actually be updated to reflect vague points 
clarified during discussion.  As it is, there are a lot of points that 
have been clarified, and questions answered, but they're strewn across 
100 different posts.  I'm pretty lost.  I gave up trying to follow this 
myself.  I'm hoping you'll figure it out and post something coherent. :-)

On the bright side, thanks to Andrei, at least there *is* an open 
discussion going on about the feature before it just shows up in the 
change log as a done deal.

--bb
Mar 19 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Derek Parnell wrote:

 On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:


 I wish it wasn't so hard to get a simple straight answer from the 
 experts.


 
 I think discussion would much improved if big changes like this actually 
 came with a detailed proposal on a website somewhere that people could 
 refer to and which would actually be updated to reflect vague points 
 clarified during discussion.  As it is, there are a lot of points that 
 have been clarified, and questions answered, but they're strewn across 
 100 different posts.  I'm pretty lost.  I gave up trying to follow this 
 myself.  I'm hoping you'll figure it out and post something coherent. :-)
 
 On the bright side, thanks to Andrei, at least there *is* an open 
 discussion going on about the feature before it just shows up in the 
 change log as a done deal.


I agree. (How couldn't I? Flattery goes a long way :o).)

Maybe we could imitate what other languages do, e.g. Perl has the famous 
"apocalypses" that describe each language feature in detail.


Andrei
Mar 19 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Bill Baxter wrote:

 Derek Parnell wrote:

 On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:


 I wish it wasn't so hard to get a simple straight answer from the 
 experts.


 I think discussion would much improved if big changes like this 
 actually came with a detailed proposal on a website somewhere that 
 people could refer to and which would actually be updated to reflect 
 vague points clarified during discussion.  As it is, there are a lot 
 of points that have been clarified, and questions answered, but 
 they're strewn across 100 different posts.  I'm pretty lost.  I gave 
 up trying to follow this myself.  I'm hoping you'll figure it out and 
 post something coherent. :-)

 On the bright side, thanks to Andrei, at least there *is* an open 
 discussion going on about the feature before it just shows up in the 
 change log as a done deal.


 
 I agree. (How couldn't I? Flattery goes a long way :o).)
 
 Maybe we could imitate what other languages do, e.g. Perl has the famous 
 "apocalypses" that describe each language feature in detail.


I was thinking more of Python's PEPs, but yeh, same deal.  I like PEPs 
in that anyone can submit one, get it assigned an offical number.   As 
opposed to Larry's stone tablets brought down from the mountain top for 
the rest of us to ooh and ahh over.  Python's way is a little more 
egalitarian.

Semi-official Enhancement Proposals are also a good way to handle the 
many repeated requests for 'feature X'.   Just tell 'em -- great idea, 
now go write a DEP for it.  If they actually do it, then great.  Next 
time someone asks for the feature you just point 'em to the previous DEP 
and the BFD ruling on it.

My impression is that PEPs get weighted somehow based on how fleshed-out 
they are.  For instance it seems a majority of PEPs (at least the ones 
I've read) come complete with prototype implementations.  So PEP is more 
than just a vague wish like "Please implement Java-style serialization". 
  It has to contain the nitty gritty details.

--bb
Mar 19 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:
 

 Bill Baxter wrote:


 Derek Parnell wrote:


 On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See Website 
 For
 Email) wrote:


 I wish it wasn't so hard to get a simple straight answer from the 
 experts.



 I think discussion would much improved if big changes like this 
 actually came with a detailed proposal on a website somewhere that 
 people could refer to and which would actually be updated to reflect 
 vague points clarified during discussion.  As it is, there are a lot 
 of points that have been clarified, and questions answered, but 
 they're strewn across 100 different posts.  I'm pretty lost.  I gave 
 up trying to follow this myself.  I'm hoping you'll figure it out and 
 post something coherent. :-)

 On the bright side, thanks to Andrei, at least there *is* an open 
 discussion going on about the feature before it just shows up in the 
 change log as a done deal.



 I agree. (How couldn't I? Flattery goes a long way :o).)

 Maybe we could imitate what other languages do, e.g. Perl has the 
 famous "apocalypses" that describe each language feature in detail.


 
 
 I was thinking more of Python's PEPs, but yeh, same deal.  I like PEPs 
 in that anyone can submit one, get it assigned an offical number.   As 
 opposed to Larry's stone tablets brought down from the mountain top for 
 the rest of us to ooh and ahh over.  Python's way is a little more 
 egalitarian.
 
 Semi-official Enhancement Proposals are also a good way to handle the 
 many repeated requests for 'feature X'.   Just tell 'em -- great idea, 
 now go write a DEP for it.  If they actually do it, then great.  Next 
 time someone asks for the feature you just point 'em to the previous DEP 
 and the BFD ruling on it.
 
 My impression is that PEPs get weighted somehow based on how fleshed-out 
 they are.  For instance it seems a majority of PEPs (at least the ones 
 I've read) come complete with prototype implementations.  So PEP is more 
 than just a vague wish like "Please implement Java-style serialization". 
  It has to contain the nitty gritty details.
 
 --bb


The PEP numbers are also a convenient way to refer to certain issues or 
features: "Oh the 'with' statement? That's PEP 343." The PEP can also 
serve as a starting point for the official documentation of the feature.

Most importantly, they serve as a fixed locus of discussion, and can 
vastly improve the low signal-to-noise ratio that running around in 
circles on a mailing list or newsgroup can cause.

In other words:
DEPs++

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Mar 19 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Kirk McDonald wrote:

 Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:


 Bill Baxter wrote:


 Derek Parnell wrote:


 On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See 
 Website For
 Email) wrote:


 I wish it wasn't so hard to get a simple straight answer from the 
 experts.



 I think discussion would much improved if big changes like this 
 actually came with a detailed proposal on a website somewhere that 
 people could refer to and which would actually be updated to reflect 
 vague points clarified during discussion.  As it is, there are a lot 
 of points that have been clarified, and questions answered, but 
 they're strewn across 100 different posts.  I'm pretty lost.  I gave 
 up trying to follow this myself.  I'm hoping you'll figure it out 
 and post something coherent. :-)

 On the bright side, thanks to Andrei, at least there *is* an open 
 discussion going on about the feature before it just shows up in the 
 change log as a done deal.



 I agree. (How couldn't I? Flattery goes a long way :o).)

 Maybe we could imitate what other languages do, e.g. Perl has the 
 famous "apocalypses" that describe each language feature in detail.



 I was thinking more of Python's PEPs, but yeh, same deal.  I like PEPs 
 in that anyone can submit one, get it assigned an offical number.   As 
 opposed to Larry's stone tablets brought down from the mountain top 
 for the rest of us to ooh and ahh over.  Python's way is a little more 
 egalitarian.

 Semi-official Enhancement Proposals are also a good way to handle the 
 many repeated requests for 'feature X'.   Just tell 'em -- great idea, 
 now go write a DEP for it.  If they actually do it, then great.  Next 
 time someone asks for the feature you just point 'em to the previous 
 DEP and the BFD ruling on it.

 My impression is that PEPs get weighted somehow based on how 
 fleshed-out they are.  For instance it seems a majority of PEPs (at 
 least the ones I've read) come complete with prototype 
 implementations.  So PEP is more than just a vague wish like "Please 
 implement Java-style serialization".  It has to contain the nitty 
 gritty details.

 --bb


 
 The PEP numbers are also a convenient way to refer to certain issues or 
 features: "Oh the 'with' statement? That's PEP 343." The PEP can also 
 serve as a starting point for the official documentation of the feature.
 
 Most importantly, they serve as a fixed locus of discussion, and can 
 vastly improve the low signal-to-noise ratio that running around in 
 circles on a mailing list or newsgroup can cause.
 
 In other words:
 DEPs++


I, too, think that's a great idea.

Andrei
Mar 19 2007
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Mar 2007 08:29:31 +0900, Bill Baxter wrote:


 On the bright side, thanks to Andrei, at least there *is* an open 
 discussion going on about the feature before it just shows up in the 
 change log as a done deal.


Amen to that. 

A *HUGE* thank you to Andrei for being so available and willing to suffer
fools gladly. This discussions extremely important for everybody an the big
W just can't do it all. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
20/03/2007 10:49:22 AM
Mar 19 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Tue, 20 Mar 2007 08:29:31 +0900, Bill Baxter wrote:
 

 On the bright side, thanks to Andrei, at least there *is* an open 
 discussion going on about the feature before it just shows up in the 
 change log as a done deal.


 
 Amen to that. 
 
 A *HUGE* thank you to Andrei for being so available and willing to suffer
 fools gladly. This discussions extremely important for everybody an the big
 W just can't do it all. 


I thank you folks. Sharing is great. Studying alone is learning from a fool.

Andrei
Mar 19 2007
prev sibling parent reply jovo <jovo at.home> writes:
Derek Parnell Wrote:

 
   const char[] s;    // ok
   ...
   s[0] = 'a'; // fails
   s    = "new data"; //ok
   s.length = 2; // ok
 


No, it can not.
 
const int[] a = [1, 2, 3, 4]; 
a.length = 2; // ok?
some_var = a[3]; // oops!
 
But length is not field.
 
jovo
Mar 20 2007
parent jovo <jovo at.home> writes:
jovo Wrote:


 Derek Parnell Wrote:

 
   const char[] s;    // ok
   ...
   s[0] = 'a'; // fails
   s    = "new data"; //ok
   s.length = 2; // ok
 


 
 No, it can not.
  
 const int[] a = [1, 2, 3, 4]; 
 a.length = 2; // ok?
 some_var = a[3]; // oops!
  


Ooops! :)
May be it's more logical then I was thinking.

There are will be always tension between consistency,
convenience and efficiency of generated code.
Actually I like general D's approach.

jovo
Mar 20 2007
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 By the way, a couple of days ago I've had an idea. Many people here ask
 for a "string" alias because char[] is a tad hard to type and uneasy on
 the eyes. Probably a good candidate would be:
 
 alias invariant char[] string;
 


Now that I like. Reminds me very much of Python.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Mar 19 2007
prev sibling parent reply jovo <jovo at.home> writes:
Andrei Alexandrescu (See Website For Email) Wrote:


 (Reposted after cleanup :o))
 
 kris wrote:

 How about some further example? Given these sigs:
 
 struct Foo
 {
    int a;
 }
 
 class Bar
 {
    char[] b;
 }
 
 void fooish (inout Foo foo) {}
 
 char[] barish (Bar bar) {return bar.b;}
 
 
 1) how do I modify the function decls to have the compiler *enforce* 
 readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be 
 mutated within the function body?


 
 void fooish (const ref Foo foo) {}
 



void fooish(const ref Foo foo) {
    foo.a = 1;                   // not allowed
    foo = sam_Foo;           // allowed?
    
jovo
Mar 20 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
jovo wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:
 

 (Reposted after cleanup :o))

 kris wrote:

 How about some further example? Given these sigs:

 struct Foo
 {
    int a;
 }

 class Bar
 {
    char[] b;
 }

 void fooish (inout Foo foo) {}

 char[] barish (Bar bar) {return bar.b;}


 1) how do I modify the function decls to have the compiler *enforce* 
 readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be 
 mutated within the function body?


 void fooish (const ref Foo foo) {}


 
 
 void fooish(const ref Foo foo) {
     foo.a = 1;                   // not allowed


Not allowed indeed.


     foo = sam_Foo;           // allowed?


Not allowed. The type of foo is const(ref(Foo)). When you try to assign 
to foo, you'll assign to indirectly referenced bits. If you only replace 
Foo with int (which makes sense because Foo is a struct), you'll see how 
trying to assign the int would indirectly modify memory outside the 
function.

Now consider:

void Fun(ref const Foo foo) {
}

The type of foo is ref(const(Foo)). So the function has a reference to a 
constant object. It can modify the direct fields of the object, but 
nothing beyond that. It's not a very useful case. We might even choose 
to prohibit it statically unless compelling use cases show up. I 
actually already think of a couple :o).


Andrei
Mar 20 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 Assuming that 'invariant' = really constant, 'const' = C++ 
 pseudo-const...


 
 Yah.
 

 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% 
 of my usages of 'const' to 'invariant'.


 
 Great to hear that!


Sorry, I didn't explain myself very well. I meant that this proposal 
breaks 100% of all existing D uses of const.

  >> (3) I concede the problem of association with 'readonly' and ROM. But

 the association between 'const' and 'constant' is pretty strong.


 
 I think there's universal agreement that you can't express tersely the 
 two notions "const-as-in-C++" and "const-as-in-we-really-mean-it". 
 Probably it's best to just go with two terms and move on.


I completely agree with this. The gripe I have is that 'const' is a 
completely inappropriate term for 'const-as-in-C++'. It's a bizarre 
misnomer to use 'const' to mean "don't touch". The only benefit (albeit 
a considerable one) of this nomenclature is compatibility with C++ 
nomenclature, especially the term "const correctness".
D currently has a 'const' which actually means "constant", it seems 
dreadful to exchange that for a clearly inferior "don't touch" meaning.
I'm concerned that you may have spent so much time in C++ that you've 
become accustomed to "const" == "don't touch"; all of my previous posts 
have been arguing that this is a grossly unnatural association.

It is possible that the C++ misnomer is so entrenched that D needs to 
perpetuate it, even at the expense of breaking all existing D code that 
uses 'const'.

But then this really surprises me:


 final int a = 2;
 
 void f(final int b)
 {
 }
 The choice of "final" in the second case prevents f from changing its argument,
 and it's the free will choice of f's author. The "final" does not
 influence f's signature or how other people use it.
 It's just constraining f's implementation.


because it seems that that we still have 'const' surprises for C++ refugees.
Mar 20 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Don Clugston wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% 
 of my usages of 'const' to 'invariant'.


 Great to hear that!


 
 Sorry, I didn't explain myself very well. I meant that this proposal 
 breaks 100% of all existing D uses of const.


Ah, so I /did/ read that right.


  >> (3) I concede the problem of association with 'readonly' and ROM. But

 the association between 'const' and 'constant' is pretty strong.


 I think there's universal agreement that you can't express tersely the 
 two notions "const-as-in-C++" and "const-as-in-we-really-mean-it". 
 Probably it's best to just go with two terms and move on.


 
 I completely agree with this. The gripe I have is that 'const' is a 
 completely inappropriate term for 'const-as-in-C++'. It's a bizarre 
 misnomer to use 'const' to mean "don't touch". The only benefit (albeit 
 a considerable one) of this nomenclature is compatibility with C++ 
 nomenclature, especially the term "const correctness".
 D currently has a 'const' which actually means "constant", it seems 
 dreadful to exchange that for a clearly inferior "don't touch" meaning.
 I'm concerned that you may have spent so much time in C++ that you've 
 become accustomed to "const" == "don't touch"; all of my previous posts 
 have been arguing that this is a grossly unnatural association.


I completely agree with *that* :).


 It is possible that the C++ misnomer is so entrenched that D needs to 
 perpetuate it, even at the expense of breaking all existing D code that 
 uses 'const'.


And I really hope this is not the case.


 But then this really surprises me:
 

 final int a = 2;

 void f(final int b)
 {
 }
 The choice of "final" in the second case prevents f from changing its 
 argument,


  > and it's the free will choice of f's author. The "final" does not
  > influence f's signature or how other people use it.
  > It's just constraining f's implementation.
 
 because it seems that that we still have 'const' surprises for C++ 
 refugees.


I don't see how this would be a surprise for anyone coming from C++. 
This is exactly how 'const' works for value types, isn't it? (Do this 
with reference types on the other hand, and I could see them being a bit 
confused)

The thing to keep in mind is that 'b' is a new variable (kept on the 
stack) that happens to have the same value as whatever was passed to the 
function. If that variable happens not to be changed by the code where 
it's in scope, that doesn't effect other code in any way at all.
In other words: There's no way to tell the difference from outside of 
the function, so why would it change the signature?
Mar 20 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Frits van Bommel wrote:

 Don Clugston wrote:

 But then this really surprises me:


 final int a = 2;

 void f(final int b)
 {
 }
 The choice of "final" in the second case prevents f from changing its 
 argument,


  > and it's the free will choice of f's author. The "final" does not
  > influence f's signature or how other people use it.
  > It's just constraining f's implementation.

 because it seems that that we still have 'const' surprises for C++ 
 refugees.


 
 I don't see how this would be a surprise for anyone coming from C++. 
 This is exactly how 'const' works for value types, isn't it?


Yes. The point is that for some uses of C++ const, you have to use 
'const', while for others you need to use 'final'. I feel that this 
weakens the argument for using the word 'const' in the C++ sense. The 
hypothetical C++ refugee is still going to have culture shock when using 
D const.
Mar 20 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Don Clugston wrote:

 Frits van Bommel wrote:

 Don Clugston wrote:

 But then this really surprises me:


 final int a = 2;

 void f(final int b)
 {
 }
 The choice of "final" in the second case prevents f from changing 
 its argument,


  > and it's the free will choice of f's author. The "final" does not
  > influence f's signature or how other people use it.
  > It's just constraining f's implementation.

 because it seems that that we still have 'const' surprises for C++ 
 refugees.


 I don't see how this would be a surprise for anyone coming from C++. 
 This is exactly how 'const' works for value types, isn't it?


 
 Yes. The point is that for some uses of C++ const, you have to use 
 'const', while for others you need to use 'final'. I feel that this 
 weakens the argument for using the word 'const' in the C++ sense. The 
 hypothetical C++ refugee is still going to have culture shock when using 
 D const.


I think the shock will be mollified by the explanation that const is for 
the stuff "before the star" and final is for the stuff "after the star".

const char *const s = "hello"; // C++

Many C++ programmers complain about this syntax, finding it silly.


Andrei
Mar 20 2007
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 I think the shock will be mollified by the explanation that const is for 
 the stuff "before the star" and final is for the stuff "after the star".
 
 const char *const s = "hello"; // C++
 
 Many C++ programmers complain about this syntax, finding it silly.


I also have to always stop and think about what it means. Const in C++ 
actually has 3 distinct meanings, and which is in force depends on the 
context.

In my discussions about this with C++ programmers, even C++ compiler 
implementors, very, very few understand just what is going on with C++ 
const. I think a lot of the confusion here about const is coming from 
the misunderstandings engendered by the C++ mechanism.

What the D proposal does is identify those 3 distinct meanings, and make 
them distinct and individually controllable. This should also, in the 
long run, make it more understandable once one is able to get past the 
wacky confusion that is C++ const.

It also gives those who care about const-correctness the mechanism to 
control precisely what they need, and it can even help the optimizer 
generate better code. (C++ const is worthless for generating better code.)
Mar 20 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 Frits van Bommel wrote:

 Don Clugston wrote:

 But then this really surprises me:


 final int a = 2;

 void f(final int b)
 {
 }
 The choice of "final" in the second case prevents f from changing 
 its argument,


  > and it's the free will choice of f's author. The "final" does not
  > influence f's signature or how other people use it.
  > It's just constraining f's implementation.

 because it seems that that we still have 'const' surprises for C++ 
 refugees.


 I don't see how this would be a surprise for anyone coming from C++. 
 This is exactly how 'const' works for value types, isn't it?


 Yes. The point is that for some uses of C++ const, you have to use 
 'const', while for others you need to use 'final'. I feel that this 
 weakens the argument for using the word 'const' in the C++ sense. The 
 hypothetical C++ refugee is still going to have culture shock when 
 using D const.


 
 I think the shock will be mollified by the explanation that const is for 
 the stuff "before the star" and final is for the stuff "after the star".
 
 const char *const s = "hello"; // C++
 
 Many C++ programmers complain about this syntax, finding it silly.
 
 
 Andrei


Huh? Wait a second, but won't D have the same issue, albeit with 
'final'? For example, suppose you have:
   final Foo foo;
then what is:
   typeof(&foo)
?





-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 20 2007
parent reply Tyler Knott <tywebmail mailcity.com> writes:
Bruno Medeiros wrote:

 
 Huh? Wait a second, but won't D have the same issue, albeit with 
 'final'? For example, suppose you have:
   final Foo foo;
 then what is:
   typeof(&foo)
 ?
 


invariant Foo* or const Foo*, depending on whichever is most appropriate for
the situation.  I'd guess that invariant 
Foo* would be the default because it's semantically closest to what is being
expressed (a pointer to immutable data), 
though const Foo* is also allowable because you can't modify data through const
pointers either.
Mar 20 2007
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Tyler Knott wrote:

 Bruno Medeiros wrote:

 Huh? Wait a second, but won't D have the same issue, albeit with 
 'final'? For example, suppose you have:
   final Foo foo;
 then what is:
   typeof(&foo)
 ?


 
 invariant Foo* or const Foo*, depending on whichever is most appropriate 
 for the situation.  I'd guess that invariant Foo* would be the default 
 because it's semantically closest to what is being expressed (a pointer 
 to immutable data), though const Foo* is also allowable because you 
 can't modify data through const pointers either.


As I understand, there will be an implicit cast of mutables to immutables, so
assuming 
'const' appears under 'invariant' in this list, I would expect|hope it to be
'const Foo*' 
so that it is passable to either 'const' or 'invariant' typed parameters.  Ie:

final Foo foo;

void alpha (invariant Foo x) {...}
void beta (const Foo x) {...}

auto ptr = &foo;
alpha(*foo); // no problem regardless
beta(*foo); // an issue if ptr is invariant

Again, this is /if/ the casting rules will be as I think they will.  I'm just
now starting 
to wrap my own head around it.

Presumably if I really /want/ it to be invariant, I could maybe do this?
invariant ptr = &foo;

Which would perform the mentioned implicit cast before assignment, discarding
the 
potential 'const' view.

-- Chris Nicholson-Sauls
Mar 20 2007
parent reply Tyler Knott <tywebmail mailcity.com> writes:
Chris Nicholson-Sauls wrote:

 As I understand, there will be an implicit cast of mutables to 
 immutables, so assuming 'const' appears under 'invariant' in this list, 
 I would expect|hope it to be 'const Foo*' so that it is passable to 
 either 'const' or 'invariant' typed parameters.  Ie:
 


Actually, I take back what I said in my previous post in this thread.  Taking
the address of a final variable should 
always result in an invariant pointer.  The reason is that invariant references
require the data they reference to 
never, ever change whereas const references expect the data they reference to
be changed by other 
non-const/non-immutable references to that data.  Obviously, since const
references can't guarantee the data they 
reference won't change they can't be cast to immutable references at all, but
because const references can still 
guarantee they won't mutate the data they reference immutable references can be
freely cast to const references.
Mar 20 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Tyler Knott wrote:

 Chris Nicholson-Sauls wrote:

 As I understand, there will be an implicit cast of mutables to 
 immutables, so assuming 'const' appears under 'invariant' in this 
 list, I would expect|hope it to be 'const Foo*' so that it is passable 
 to either 'const' or 'invariant' typed parameters.  Ie:


 
 Actually, I take back what I said in my previous post in this thread.  
 Taking the address of a final variable should always result in an 
 invariant pointer.  The reason is that invariant references require the 
 data they reference to never, ever change whereas const references 
 expect the data they reference to be changed by other 
 non-const/non-immutable references to that data.  Obviously, since const 
 references can't guarantee the data they reference won't change they 
 can't be cast to immutable references at all, but because const 
 references can still guarantee they won't mutate the data they reference 
 immutable references can be freely cast to const references.


Well, yes, but is 'invariant' transitive like const? I think it is (but 
I'm not sure, I'm getting a bit lost in the thread), and if it is, those 
semantics won't work. I.e., "typeof(&foo) " in my example can't be 
invariant anything.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 22 2007
next sibling parent Tyler Knott <tywebmail mailcity.com> writes:
Bruno Medeiros wrote:

 Well, yes, but is 'invariant' transitive like const? I think it is (but 
 I'm not sure, I'm getting a bit lost in the thread), and if it is, those 
 semantics won't work. I.e., "typeof(&foo) " in my example can't be 
 invariant anything.
 


D'oh, of course!  It's legal to modify data referenced by foo, which makes it
incompatible with invariant pointers, but 
which is fine for const pointers.  I think const pointer is the correct answer
for typeof(&foo).
Mar 22 2007
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bruno Medeiros wrote:

 Tyler Knott wrote:

 Chris Nicholson-Sauls wrote:

 As I understand, there will be an implicit cast of mutables to 
 immutables, so assuming 'const' appears under 'invariant' in this 
 list, I would expect|hope it to be 'const Foo*' so that it is 
 passable to either 'const' or 'invariant' typed parameters.  Ie:


 Actually, I take back what I said in my previous post in this thread.  
 Taking the address of a final variable should always result in an 
 invariant pointer.  The reason is that invariant references require 
 the data they reference to never, ever change whereas const references 
 expect the data they reference to be changed by other 
 non-const/non-immutable references to that data.  Obviously, since 
 const references can't guarantee the data they reference won't change 
 they can't be cast to immutable references at all, but because const 
 references can still guarantee they won't mutate the data they 
 reference immutable references can be freely cast to const references.


 
 Well, yes, but is 'invariant' transitive like const? I think it is (but 
 I'm not sure, I'm getting a bit lost in the thread), and if it is, those 
 semantics won't work. I.e., "typeof(&foo) " in my example can't be 
 invariant anything.
 


Actually, having thought over it a few times, what I would really expect is not
a "const 
pointer to a Foo", but rather a "const(pointer to a Foo)"...

final Foo foo;

auto ptr = &foo; // const(Foo*)

Hmm.  Baffling.  I almost give up.

-- Chris Nicholson-Sauls
Mar 23 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Chris Nicholson-Sauls wrote:

 Bruno Medeiros wrote:

 Tyler Knott wrote:

 Chris Nicholson-Sauls wrote:

 As I understand, there will be an implicit cast of mutables to 
 immutables, so assuming 'const' appears under 'invariant' in this 
 list, I would expect|hope it to be 'const Foo*' so that it is 
 passable to either 'const' or 'invariant' typed parameters.  Ie:


 Actually, I take back what I said in my previous post in this 
 thread.  Taking the address of a final variable should always result 
 in an invariant pointer.  The reason is that invariant references 
 require the data they reference to never, ever change whereas const 
 references expect the data they reference to be changed by other 
 non-const/non-immutable references to that data.  Obviously, since 
 const references can't guarantee the data they reference won't change 
 they can't be cast to immutable references at all, but because const 
 references can still guarantee they won't mutate the data they 
 reference immutable references can be freely cast to const references.


 Well, yes, but is 'invariant' transitive like const? I think it is 
 (but I'm not sure, I'm getting a bit lost in the thread), and if it 
 is, those semantics won't work. I.e., "typeof(&foo) " in my example 
 can't be invariant anything.


 
 Actually, having thought over it a few times, what I would really expect 
 is not a "const pointer to a Foo", but rather a "const(pointer to a 
 Foo)"...
 
 final Foo foo;
 
 auto ptr = &foo; // const(Foo*)
 
 Hmm.  Baffling.  I almost give up.


Don't. It's entirely understandable to be confused. Extremely little 
information has been given to date. Once that information will come in 
proper book format, it will be very easy to understand.

Andrei
Mar 23 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Tyler Knott wrote:

 Bruno Medeiros wrote:

 Huh? Wait a second, but won't D have the same issue, albeit with 
 'final'? For example, suppose you have:
   final Foo foo;
 then what is:
   typeof(&foo)
 ?


 
 invariant Foo* or const Foo*, depending on whichever is most appropriate 
 for the situation.  I'd guess that invariant Foo* would be the default 
 because it's semantically closest to what is being expressed (a pointer 
 to immutable data), though const Foo* is also allowable because you 
 can't modify data through const pointers either.


Let's suppose it's  const Foo*  (the less restrictive option). Even so, 
you will be restricting the type more than necessary, thus loosing some 
range of freedom. Because with  const Foo*  you can't change members of 
Foo*, while with final Foo, you can change members of foo. I.e.:

   final Foo foo;
   foo.x = 2;   // ok

   typeof(&foo) fooptr = &foo;
   (*fooptr.x) = 2;   // not allowed

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 22 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bruno Medeiros wrote:

 Tyler Knott wrote:

 Bruno Medeiros wrote:

 Huh? Wait a second, but won't D have the same issue, albeit with
 'final'? For example, suppose you have:
   final Foo foo;
 then what is:
   typeof(&foo)
 ?


 invariant Foo* or const Foo*, depending on whichever is most
 appropriate for the situation.  I'd guess that invariant Foo* would be
 the default because it's semantically closest to what is being
 expressed (a pointer to immutable data), though const Foo* is also
 allowable because you can't modify data through const pointers either.


 
 Let's suppose it's  const Foo*  (the less restrictive option). Even so,
 you will be restricting the type more than necessary, thus loosing some
 range of freedom. Because with  const Foo*  you can't change members of
 Foo*, while with final Foo, you can change members of foo. I.e.:
 
   final Foo foo;
   foo.x = 2;   // ok
 
   typeof(&foo) fooptr = &foo;
   (*fooptr.x) = 2;   // not allowed


I guess the only way to solve that is to parameterise const and invariant...


 final Foo foo;
 final invariant Foo bar;
 writefln("%s", typeinfo(typeof(&foo)));
 writefln("%s", typeinfo(typeof(&bar)));

 --> invariant(1) Foo
     invariant(*) Foo


Honestly, I don't think that's going to happen :P

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 22 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Daniel Keep wrote:

 
 Bruno Medeiros wrote:

 Tyler Knott wrote:

 Bruno Medeiros wrote:

 Huh? Wait a second, but won't D have the same issue, albeit with
 'final'? For example, suppose you have:
   final Foo foo;
 then what is:
   typeof(&foo)
 ?


 invariant Foo* or const Foo*, depending on whichever is most
 appropriate for the situation.  I'd guess that invariant Foo* would be
 the default because it's semantically closest to what is being
 expressed (a pointer to immutable data), though const Foo* is also
 allowable because you can't modify data through const pointers either.


 Let's suppose it's  const Foo*  (the less restrictive option). Even so,
 you will be restricting the type more than necessary, thus loosing some
 range of freedom. Because with  const Foo*  you can't change members of
 Foo*, while with final Foo, you can change members of foo. I.e.:

   final Foo foo;
   foo.x = 2;   // ok

   typeof(&foo) fooptr = &foo;
   (*fooptr.x) = 2;   // not allowed


 
 I guess the only way to solve that is to parameterise const and invariant...
 

 final Foo foo;
 final invariant Foo bar;
 writefln("%s", typeinfo(typeof(&foo)));
 writefln("%s", typeinfo(typeof(&bar)));

 --> invariant(1) Foo
     invariant(*) Foo


 
 Honestly, I don't think that's going to happen :P
 
 	-- Daniel
 


No, another way to solve that is to have 'final' be a type modifier as well:

   typeof(&foo)  --> (final Foo)*

This is essentially exactly like C++'s 'const'. (and like the 'rdonly' 
in my "hobbyist" design.)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bruno Medeiros wrote:

 Daniel Keep wrote:

 Bruno Medeiros wrote:

 Tyler Knott wrote:

 Bruno Medeiros wrote:

 Huh? Wait a second, but won't D have the same issue, albeit with
 'final'? For example, suppose you have:
   final Foo foo;
 then what is:
   typeof(&foo)
 ?


 invariant Foo* or const Foo*, depending on whichever is most
 appropriate for the situation.  I'd guess that invariant Foo* would be
 the default because it's semantically closest to what is being
 expressed (a pointer to immutable data), though const Foo* is also
 allowable because you can't modify data through const pointers either.


 Let's suppose it's  const Foo*  (the less restrictive option). Even so,
 you will be restricting the type more than necessary, thus loosing some
 range of freedom. Because with  const Foo*  you can't change members of
 Foo*, while with final Foo, you can change members of foo. I.e.:

   final Foo foo;
   foo.x = 2;   // ok

   typeof(&foo) fooptr = &foo;
   (*fooptr.x) = 2;   // not allowed


 I guess the only way to solve that is to parameterise const and
 invariant...


 final Foo foo;
 final invariant Foo bar;
 writefln("%s", typeinfo(typeof(&foo)));
 writefln("%s", typeinfo(typeof(&bar)));

 --> invariant(1) Foo
     invariant(*) Foo


 Honestly, I don't think that's going to happen :P

     -- Daniel


 
 No, another way to solve that is to have 'final' be a type modifier as
 well:
 
   typeof(&foo)  --> (final Foo)*
 
 This is essentially exactly like C++'s 'const'. (and like the 'rdonly'
 in my "hobbyist" design.)


I think the problem with that is that

  final pi = 3.1415...;

then doesn't do what you think it does.  If pi is now of type final
real, then you would still be able to re-assign it.

  final e = 2.14...;
  pi = e;

We probably *could* make it so that you can't assign to a variable
that's got a final'ed type, but then it's acting like a storage class,
not as a type.

I dunno.  This whole thread is just giving me a headache... I *thought*
I understood it after the first post, but now my head hurts and I'm not
so sure :P

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 23 2007
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Don Clugston wrote:


 I completely agree with this. The gripe I have is that 'const' is a
 completely inappropriate term for 'const-as-in-C++'. It's a bizarre
 misnomer to use 'const' to mean "don't touch". The only benefit (albeit
 a considerable one) of this nomenclature is compatibility with C++
 nomenclature, especially the term "const correctness".
 D currently has a 'const' which actually means "constant", it seems
 dreadful to exchange that for a clearly inferior "don't touch" meaning.
 I'm concerned that you may have spent so much time in C++ that you've
 become accustomed to "const" == "don't touch"; all of my previous posts
 have been arguing that this is a grossly unnatural association.
 
 It is possible that the C++ misnomer is so entrenched that D needs to
 perpetuate it, even at the expense of breaking all existing D code that
 uses 'const'.


I agree with Don here.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Mar 20 2007
parent reply kris <foo bar.com> writes:
Lars Ivar Igesund wrote:

 Don Clugston wrote:
 
 

I completely agree with this. The gripe I have is that 'const' is a
completely inappropriate term for 'const-as-in-C++'. It's a bizarre
misnomer to use 'const' to mean "don't touch". The only benefit (albeit
a considerable one) of this nomenclature is compatibility with C++
nomenclature, especially the term "const correctness".
D currently has a 'const' which actually means "constant", it seems
dreadful to exchange that for a clearly inferior "don't touch" meaning.
I'm concerned that you may have spent so much time in C++ that you've
become accustomed to "const" == "don't touch"; all of my previous posts
have been arguing that this is a grossly unnatural association.

It is possible that the C++ misnomer is so entrenched that D needs to
perpetuate it, even at the expense of breaking all existing D code that
uses 'const'.


 
 
 I agree with Don here.



So do I

Was somewhat hoping invariant would be used in place of what has now 
taken shape as "const", and "constant" would be used in place of where 
"invariant" has landed. Then there would be no "const" to confuse 
anyone. Almost seems as though shortening the name by a couple of bytes 
is actually more important than the meaning of the words in use?

I'm not sure about "breaking all existing D code" ... there would seem 
to be very little use of "const" at this time, because the current 
semantics are really kinda worthless; e.g. one should probably use enum 
for most things 'constant', except you can't have "enum : char[]" making 
enum notably less useful than it could otherwise be.

Where does enum fit in this picture anyway? Can it recover some duty 
from "const" and/or "final" in a logical and consistent manner?
Mar 20 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
kris wrote:

 Lars Ivar Igesund wrote:

 Don Clugston wrote:



 I completely agree with this. The gripe I have is that 'const' is a
 completely inappropriate term for 'const-as-in-C++'. It's a bizarre
 misnomer to use 'const' to mean "don't touch". The only benefit (albeit
 a considerable one) of this nomenclature is compatibility with C++
 nomenclature, especially the term "const correctness".
 D currently has a 'const' which actually means "constant", it seems
 dreadful to exchange that for a clearly inferior "don't touch" meaning.
 I'm concerned that you may have spent so much time in C++ that you've
 become accustomed to "const" == "don't touch"; all of my previous posts
 have been arguing that this is a grossly unnatural association.

 It is possible that the C++ misnomer is so entrenched that D needs to
 perpetuate it, even at the expense of breaking all existing D code that
 uses 'const'.



 I agree with Don here.


 
 
 So do I
 
 Was somewhat hoping invariant would be used in place of what has now 
 taken shape as "const", and "constant" would be used in place of where 
 "invariant" has landed. Then there would be no "const" to confuse 
 anyone. Almost seems as though shortening the name by a couple of bytes 
 is actually more important than the meaning of the words in use?


I think the 5 letters to 9 letters a difference, especially when 
repeated many times. And again: invariant and const are synonims. 
Merriam-Webster lists "constant" as the first meaning of "invariant":

http://m-w.com/dictionary/invariant


 I'm not sure about "breaking all existing D code" ... there would seem 
 to be very little use of "const" at this time, because the current 
 semantics are really kinda worthless; e.g. one should probably use enum 
 for most things 'constant', except you can't have "enum : char[]" making 
 enum notably less useful than it could otherwise be.
 
 Where does enum fit in this picture anyway? Can it recover some duty 
 from "const" and/or "final" in a logical and consistent manner?


If I had my way, I'd make the language powerful enough to express 
enumerated types in stdlib, then I'd deprecate the built-in one.


Andrei
Mar 20 2007
parent kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 kris wrote:


[snip]

 Was somewhat hoping invariant would be used in place of what has now 
 taken shape as "const", and "constant" would be used in place of where 
 "invariant" has landed. Then there would be no "const" to confuse 
 anyone. Almost seems as though shortening the name by a couple of 
 bytes is actually more important than the meaning of the words in use?


 
 
 I think the 5 letters to 9 letters a difference, especially when 
 repeated many times. And again: invariant and const are synonims. 
 Merriam-Webster lists "constant" as the first meaning of "invariant":
 
 http://m-w.com/dictionary/invariant


Yeah, I know. Except there's three flies in the ointment:

1) you've already suggested "const" won't get used all that much (or can 
be implied/inferred instead).

2) Then there's the question of whether "constant" is a more appropriate 
term for what "invariant" is slated to do.

3) Additionally, it may well be better to dump "const" altogether simply 
to alleviate potential confusion.

It's hardly a life or death scenario, yet the choices being made really 
do appear to be slanted towards "something" that just doesn't seem 
entirely sensible



 I'm not sure about "breaking all existing D code" ... there would seem 
 to be very little use of "const" at this time, because the current 
 semantics are really kinda worthless; e.g. one should probably use 
 enum for most things 'constant', except you can't have "enum : char[]" 
 making enum notably less useful than it could otherwise be.

 Where does enum fit in this picture anyway? Can it recover some duty 
 from "const" and/or "final" in a logical and consistent manner?


 
 
 If I had my way, I'd make the language powerful enough to express 
 enumerated types in stdlib, then I'd deprecate the built-in one.


Would be good to make the type system more flexible and extensible, but 
that's getting away from the point: enum represents 'constant' values, 
so presumably has some bearing upon this discussion?
Mar 20 2007
prev sibling next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Don Clugston wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 Assuming that 'invariant' = really constant, 'const' = C++ 
 pseudo-const...


 Yah.


 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100% 
 of my usages of 'const' to 'invariant'.


 Great to hear that!


 
 Sorry, I didn't explain myself very well. I meant that this proposal 
 breaks 100% of all existing D uses of const.


I don't think so. Const becomes less precise, but maybe code wasn't 
using it with all the precision anyway. I actually suspect the new 
semantics will break very little code.


  >> (3) I concede the problem of association with 'readonly' and ROM. But

 the association between 'const' and 'constant' is pretty strong.


 I think there's universal agreement that you can't express tersely the 
 two notions "const-as-in-C++" and "const-as-in-we-really-mean-it". 
 Probably it's best to just go with two terms and move on.


 
 I completely agree with this. The gripe I have is that 'const' is a 
 completely inappropriate term for 'const-as-in-C++'. It's a bizarre 
 misnomer to use 'const' to mean "don't touch".


The problem is that we don't have a "nomer". Every good short name we 
considered would be as imprecise or more. There's no obvious choice that 
everybody's like, "those idiots! why did they _refuse_ to do it that 
way?" And it's telling that every single person who didn't like "const" 
with the intended meaning failed to come with an obviously better choice.


 The only benefit (albeit 
 a considerable one) of this nomenclature is compatibility with C++ 
 nomenclature, especially the term "const correctness".


Right. Imagine us coming with the "dontouch correctness" :o).


 D currently has a 'const' which actually means "constant", it seems 
 dreadful to exchange that for a clearly inferior "don't touch" meaning.


It's not "inferior". If it were inferior, we'd take it out of the 
language. Today's "const" semantics are restrictive in ways that 
severely limit its usefulness (e.g. you can't pass data modifiable in a 
module to functions guaranteed to NOT modify data in another module). 
The new const will allow that, and that's great. It's not inferior.


 I'm concerned that you may have spent so much time in C++ that you've 
 become accustomed to "const" == "don't touch"; all of my previous posts 
 have been arguing that this is a grossly unnatural association.


I completely hear you. Yet you are failing to follow with, "...when it's 
so obvious to everyone that the natural association is..."


 It is possible that the C++ misnomer is so entrenched that D needs to 
 perpetuate it, even at the expense of breaking all existing D code that 
 uses 'const'.
 But then this really surprises me:
 

 final int a = 2;

 void f(final int b)
 {
 }
 The choice of "final" in the second case prevents f from changing its 
 argument,


  > and it's the free will choice of f's author. The "final" does not
  > influence f's signature or how other people use it.
  > It's just constraining f's implementation.
 
 because it seems that that we still have 'const' surprises for C++ 
 refugees.


We can make "const" mean "final const" and drop "final", at the cost of 
disallowing correct code (e.g. functions that modify their own private 
parameters). Or we could come up with new syntax that puts "const" in a 
different position for array, e.g.:

void Fun(const char[] const s);

After considering such alternatives, final becomes much more attractive.


Andrei
Mar 20 2007
next sibling parent torhu <fake address.dude> writes:
Andrei Alexandrescu (See Website For Email) wrote:
<snip>

 We can make "const" mean "final const" and drop "final", at the cost of 
 disallowing correct code (e.g. functions that modify their own private 
 parameters). Or we could come up with new syntax that puts "const" in a 
 different position for array, e.g.:
 
 void Fun(const char[] const s);
 
 After considering such alternatives, final becomes much more attractive.



I think someone, sometime mentioned changing the meaning of the 'in' 
keyword.  I guess that would have the same meaning with functions 
parameters that is planned for const now?

void Fun(in char[] s);  // Fun can't modify the array contents

void Fun(const char[] s);


// 'in' looks nice here
char* strcpy(char* to, in char* from);
char* strcpy(char* to, const char* from);

// let's say this returns the number of irreversibly converted chars, 
like iconv does.
size_t utf8ToLatin1(in char[] from, out ubyte[] to);
size_t utf8ToLatin1(const char[] from, out ubyte[] to);


One obvious problem is that in and out would not be really opposites. 
'out' and 'inout' would take the address of the argument, but 'in' does 
nothing of the sort.  Maybe that could be confusing.
Mar 20 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 I think there's universal agreement that you can't express tersely 
 the two notions "const-as-in-C++" and 
 "const-as-in-we-really-mean-it". Probably it's best to just go with 
 two terms and move on.


 I completely agree with this. The gripe I have is that 'const' is a 
 completely inappropriate term for 'const-as-in-C++'. It's a bizarre 
 misnomer to use 'const' to mean "don't touch".


 
 The problem is that we don't have a "nomer". Every good short name we 
 considered would be as imprecise or more. There's no obvious choice that 
 everybody's like, "those idiots! why did they _refuse_ to do it that 
 way?" And it's telling that every single person who didn't like "const" 
 with the intended meaning failed to come with an obviously better choice.


Actually, I have not tried to come up with a better choice.
I still think 'readonly' captures it pretty well. I've changed my mind 
about the validity of the argument about "it's not obvious which means 
truly constant, 'const' or 'readonly'" since I feel that it applies just 
as strongly to 'const' vs 'invariant'.
My intuition would be that 'invariant' means read-only. The usage of 
'invariant' in design-by-contract is for something that can be modified 
temporarily but must ultimately be preserved; this is weaker than 
'constant'.


 The only benefit (albeit a considerable one) of this nomenclature is 
 compatibility with C++ nomenclature, especially the term "const 
 correctness".


 
 Right. Imagine us coming with the "dontouch correctness" :o).
 

 D currently has a 'const' which actually means "constant", it seems 
 dreadful to exchange that for a clearly inferior "don't touch" meaning.


 
 It's not "inferior". If it were inferior, we'd take it out of the 
 language. Today's "const" semantics are restrictive in ways that 
 severely limit its usefulness (e.g. you can't pass data modifiable in a 
 module to functions guaranteed to NOT modify data in another module).
 The new const will allow that, and that's great. It's not inferior.


I'm arguing about the name, not the semantics. The use of 'const' in the 
original post has caused no end of confusion, since it is different from 
the current D const.
To rephrase:
'const' is a very appropriate word for what 'const' does in D now: it 
defines a constant. The proposed const has an inferior connection to the 
word 'constant'.

Actually, there's a feature of the existing const which seems to be 
missing in the new proposal.

Currently, if you have
const int x = 4;

it is illegal to write &x. (just as it is illegal to write &4).
This means that the existing const cannot be subverted, even by asm 
code. (#define x 4 is similar, except untyped). Can you do this with the 
new proposal?



 I'm concerned that you may have spent so much time in C++ that you've 
 become accustomed to "const" == "don't touch"; all of my previous 
 posts have been arguing that this is a grossly unnatural association.


 
 I completely hear you. Yet you are failing to follow with, "...when it's 
 so obvious to everyone that the natural association is..."


The natural association is "const" == "never changes, under any 
circumstances". "readonly" == "don't touch".
Even for read-only memory, if you've ever used an EPROM burner, or 
flashed firmware, you know that someone can write to it. I've changed 
readonly memory, I've never changed a constant.
The concept of 'read-only' access is pretty widely understood.
Mar 21 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Don Clugston wrote:


 The natural association is "const" == "never changes, under any 
 circumstances". "readonly" == "don't touch".
 Even for read-only memory, if you've ever used an EPROM burner, or 
 flashed firmware, you know that someone can write to it. I've changed 
 readonly memory, I've never changed a constant.
 The concept of 'read-only' access is pretty widely understood.


I dunno about that.  Yes if you're talking about physical constants or 
constants like Pi, they never ever change.  But 'constant' is also used 
frequently in mathematics to mean something that's simply "not variable 
in the current context".  Like when doing partial differentiation with 
respect to y, all variables besides y are treated as constants.

And if you don't agree with me, the very first section of the Wikipedia 
on "Constant" (http://en.wikipedia.org/wiki/Constant) talks about
"unspecified constants", referring to parts of an equation that simply 
aren't variables.  But you can definitely change them if you want (the 
example they use is the Pythagorean theorem).  They are only constant 
for one particular instance of the problem.   Even if the Wikipedia 
article is way off base (the Pythagorean theorem seems a very odd choice 
to demonstrate the concept of 'constant') the fact that such text 
managed to make it onto Wikipedia indicates that the common 
understanding of the word "constant" includes more territory than you're 
apparently allowing for.

Also your definition of constant (i.e. something like Pi which 
absolutely cannot change) seems to be a more a replacement for the 
proposed 'final' as in 'final Pi = 3.14;' than for a reference whose 
referent cannot change.

So personally I'm of the opinion we should pick two words that make at 
least a modicum of sense in English, forget about what they might mean 
in C++ or Java or whatever, make sure the common one is short, easy to 
type, and easy on the eyes, and just go with it.

--bb
Mar 21 2007
parent Don Clugston <dac nospam.com.au> writes:
Bill Baxter wrote:

 Don Clugston wrote:
 

 The natural association is "const" == "never changes, under any 
 circumstances". "readonly" == "don't touch".
 Even for read-only memory, if you've ever used an EPROM burner, or 
 flashed firmware, you know that someone can write to it. I've changed 
 readonly memory, I've never changed a constant.
 The concept of 'read-only' access is pretty widely understood.


 
 I dunno about that.  Yes if you're talking about physical constants or 
 constants like Pi, they never ever change.  But 'constant' is also used 
 frequently in mathematics to mean something that's simply "not variable 
 in the current context".  Like when doing partial differentiation with 
 respect to y, all variables besides y are treated as constants.


I discussed that already. The proposed 'const' is variable in the 
current context, since (for example) another thread can change it.

If you read a value described as 'const', then read it again later, it 
is not safe to assume that it has not changed. Therefore, it is not 
constant in any meaningful sense.



 Also your definition of constant (i.e. something like Pi which 
 absolutely cannot change) seems to be a more a replacement for the 
 proposed 'final' as in 'final Pi = 3.14;' than for a reference whose 
 referent cannot change.


True. I just can't see much use for 'const' as a keyword.


 So personally I'm of the opinion we should pick two words that make at 
 least a modicum of sense in English, forget about what they might mean 
 in C++ or Java or whatever, make sure the common one is short, easy to 
 type, and easy on the eyes, and just go with it.
 
 --bb
Mar 22 2007
prev sibling parent James Dennett <jdennett acm.org> writes:
Don Clugston wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Don Clugston wrote:

 Assuming that 'invariant' = really constant, 'const' = C++
 pseudo-const...


 Yah.


 It's better than super const. However:
 (1) I would want to go through all my existing D code and change 100%
 of my usages of 'const' to 'invariant'.


 Great to hear that!


 
 Sorry, I didn't explain myself very well. I meant that this proposal
 breaks 100% of all existing D uses of const.
 
  >> (3) I concede the problem of association with 'readonly' and ROM. But

 the association between 'const' and 'constant' is pretty strong.


 I think there's universal agreement that you can't express tersely the
 two notions "const-as-in-C++" and "const-as-in-we-really-mean-it".
 Probably it's best to just go with two terms and move on.


 
 I completely agree with this. The gripe I have is that 'const' is a
 completely inappropriate term for 'const-as-in-C++'. It's a bizarre
 misnomer to use 'const' to mean "don't touch". 


Indeed, and seems to represent a misunderstand of what
const *does* mean in C++.

In this context:
  int const x(3);
it means "x is constant, i.e., cannot be changed".  In
this context:
  int const *y(&x);
it means "y is a pointer to a (possibly constant) int".
Without the const, y would not be allowed to point to
a constant int.  It doesn't mean "don't touch" -- it
means "cannot be used to alter", i.e., "leaves const
if indeed it was const".  It's closer to "won't touch".

It's clear though that the meaning confuses too many
people.  What's not clear to me is whether the proposed
terminology for D is any better.  Certainly much of
the discussion seems to be based on misstatements of
how C++ works.  There's scope to do better than C++,
but it does require understanding that on which we hope
to improve.

-- James
Mar 20 2007
prev sibling parent Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribi:

 Andrei Alexandrescu (See Website For Email) wrote:

 kris wrote:

 So, "invariant" is already a keyword ... what about that?


 I completely missed that one. I think it's a good idea to look into it 
 as a candidate for a qualifier name. Thank you.


 
 I agree. I think:
 
 final
 const
 invariant
 
 for the three cases looks pretty good.


I haven't finished reading everything on this thread yet, so I don't know if 
this has been asked. Also, I'm failing to fully understand this, but I still 
have this question: how would the following be understood by the compiler?

class A
{
	invariant
	{
		int a = 4;
		float b = -10;
	}
}

What is that? A class invariant or two invariant class members? (If the latter 
even makes sense at all...)

-- 
Carlos Santander Bernal
Mar 19 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Deewiant wrote:

 Benji Smith wrote:

 And the word "super" is now overloaded in two completely unrelated 
 concepts.


 Which isn't that rare, see the following link:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex

 I find the following examples: auto, in, is, mixin, scope, static.

 I have come to abhor the keyword "static" largely due to the above. 
 Too bad its
 various uses are unavoidably useful. <g>

 But I do agree with you, in a way. After writing the following I find my
 explanation somewhat unclear even to myself, but bear with me.

 The problem with "super const" is that "super" modifies the other 
 keyword,
 "const", instead of saying something about the 
 expression/statement/whatever (in
 this case, the type). Even "static", in all its horror, can be seen as
 specifying one of "module-level" or "compile-time". The other keywords 
 mentioned
 above use their English meaning as such an explanation, and so can be 
 understood
 without too much thought. "super const" would make "super" another 
 "static":
 lacking context, you can't be sure about about even the general 
 meaning, let
 alone the one in a specific instance.

 Upon reflection it may be moot, since one probably rarely cares about 
 keywords'
 meanings without context, but I'm sure some psychologist could come up 
 with
 something about intuitiveness which affects coding speed, or whatever.


 
 Working in NLP myself, I totally disagree. Natural language is rife with 
 homonimy and synonimy, and we're all very, very happy with that. But in 
 this case we don't even have to go that far: "super" is an adjective 
 meaning primarily "of high grade or quality" and qualifies a noun. If 
 there's no noun, you don't know what is "of high grade or quality". It's 
 a fact, and we don't even blink.
 
 The reality behind super const is that it expresses a stronger form of 
 const. It makes a lot of sense if I dub it "super const" in natural 
 language, to express it in the same way in the programming language. I 
 thought that that's too verbose and devised "const!" as a shortcut 
 (again with obvious conotations in natural language), but I'm thinking 
 of dropping it and let type inference add "super" to "const" whenever it 
 can. That should ensure exactness of the type system without verbosity 
 in source code.
 

 I'd be happiest to just get the feature as soon as possible; worrying 
 about
 keyword semantics can come later. Just like the abominations beginning 
 with
 "on_scope_". <g>


 
 Great idea. :o)
 
 
 Andrei



If you just want something that sounds like more const than const using 
existing keywords, there are other options:
   'true const'
   'double const'
   'finally const'
   'is const'
   or
   'is finally super double true const'

I kinda like 'true const' myself.  Sounds less dorky than super const to me.
:-)

--bb
Mar 16 2007
prev sibling next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)

 Andrei


 
 Really? I'd think super const would be used all the time. Anywhere a 
 class has some invariant field, it'll probably be expressed as super 
 const (if I'm understanding correctly that super const is the equivalent 
 of #define constants in C++ or static final constants in Java).
 
 Let me join the ranks of those who hate both versions of the new syntax. 
  const! looks either like a template or like "not const". You guys may 
 think you're saving a keyword, and that might be technically correct 
 from the perspective of the parser. But, for the perspective of the D 
 developer, it still looks like you've introduced a new keyword, but it's 
 a keyword that's A) nearly identical to another keyword, and B) contains 
 a symbol. Ugh. I really. Really. Really. Hate it.
 
 Using "super const" is also annoying because all of the other storage 
 classes use a single keyword. Now we've got this weird case that uses 
 two keywords. And the word "super" is now overloaded in two completely 
 unrelated concepts.
 
 (By the way, I don't like "static if" either. I think the right choice 
 would have been #if, #foreach, etc. And I think C++ made a mistake by 
 defining "long long" and "double double" types as well. Presumably, that 
 saved some keywords, but we'd all have been better off if the types were 
 defined as int8, int16, int32, int64, float32, float64, etc).
 
 I vote for "readonly" and "const". Anything else seems like a mistake.


I think that sums up my take on this pretty well. Thanks for saving me 
the typing :).
Mar 16 2007
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
I should also add that, in my opinion, any design where "const" means 
something other than "value resolved at compile time and immutable at 
runtime" would be a mistake.

(I'm not crazy about using "const" to mean "value resolved at runtime, 
and immutable after its first assignment", but I don't hate it either.)

--benji
Mar 16 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


Then how would you call "value that's not mutable through this alias" in 
a way that's not going to turn C++ immigrants away?


Andrei
Mar 16 2007
next sibling parent reply kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:
 

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 
 
 Then how would you call "value that's not mutable through this alias" in 
 a way that's not going to turn C++ immigrants away?



there are explicit names for that sort of thing; "immutable", "readonly" 
, "view" etc.  Reading through the various replies gives the impression 
that you're concerned about propogating the broken C++ semantics than 
ensuring D corrects those faults ;)

I think it's worthwhile ensuring D gets it right instead, and I'll 
happily change all of Tango to reflect that if necessary. Breaking 
source-code for a keyword that is currently used rarely is not a 
problem. Incorrect or dubious/confusing semantics are. It may be 
worthwhile dumping the "const" keyword altogether, to limit confusion.

BTW, you've also mentioned changing "inout" to "ref" instead? That would 
probably break more code than a renaming of const; I know both Tango and 
Mango use inout quite a bit, but I'm happy to change those as necessary. 
Other people likely feel the same way.

- Kris
Mar 16 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
kris wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:


 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.



 Then how would you call "value that's not mutable through this alias" 
 in a way that's not going to turn C++ immigrants away?


 
 
 there are explicit names for that sort of thing; "immutable", "readonly" 
 , "view" etc.  Reading through the various replies gives the impression 
 that you're concerned about propogating the broken C++ semantics than 
 ensuring D corrects those faults ;)
 
 I think it's worthwhile ensuring D gets it right instead, and I'll 
 happily change all of Tango to reflect that if necessary. Breaking 
 source-code for a keyword that is currently used rarely is not a 
 problem. Incorrect or dubious/confusing semantics are. It may be 
 worthwhile dumping the "const" keyword altogether, to limit confusion.
 
 BTW, you've also mentioned changing "inout" to "ref" instead? That would 
 probably break more code than a renaming of const; I know both Tango and 
 Mango use inout quite a bit, but I'm happy to change those as necessary. 
 Other people likely feel the same way.


++vote

For what it's worth, I like: 'final', 'view', and 'const' the best. 
They're all short and meaningful, given the intent for each.


Sean
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


The problem with 'view' is that it's a noun, while final and const are 
adjectives. It's very awkward to use 'view':

view int * p = &x; // huh?

Andrei
Mar 16 2007
next sibling parent kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:
 

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


 
 
 The problem with 'view' is that it's a noun, while final and const are 
 adjectives. It's very awkward to use 'view':
 
 view int * p = &x; // huh?


yuh, fair point :(
Mar 16 2007
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 14:03:13 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Sean Kelly wrote:

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


 
 The problem with 'view' is that it's a noun, 


As in "to view or not to view, that is the question" <g>


 while final and const are adjectives. 


So how does the argument from NLP about 'super' being used to qualify nouns
sound now? 


 It's very awkward to use 'view':
 view int * p = &x; // huh?


But this isn't ... ?

  super const int * p = &x; 

How about ...

  const int * const p = &x;


-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Fri, 16 Mar 2007 14:03:13 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 

 Sean Kelly wrote:

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


 The problem with 'view' is that it's a noun, 


 
 As in "to view or not to view, that is the question" <g>
 

 while final and const are adjectives. 


 
 So how does the argument from NLP about 'super' being used to qualify nouns
 sound now? 


I must not see the connection. "super const int" is a suggestive 
collocation; "view int" is not.


 It's very awkward to use 'view':
 view int * p = &x; // huh?


 
 But this isn't ... ?
 
   super const int * p = &x; 
 
 How about ...
 
   const int * const p = &x;


That's final and expresses something entirely different.


Andrei
Mar 16 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


 
 The problem with 'view' is that it's a noun, while final and const are 
 adjectives. It's very awkward to use 'view':
 
 view int * p = &x; // huh?


It's probably not terribly helpful, but 'view' is also a verb.


Sean
Mar 16 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:
 

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


 
 
 The problem with 'view' is that it's a noun, while final and const are 
 adjectives. It's very awkward to use 'view':
 
 view int * p = &x; // huh?



How about this? Using existing keywords, with a rename of "const":

1) final       - rebinding of a value to a name
2) invariant   - a read-only view of a data structure
3) constant    - a value that never changes
Mar 16 2007
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
kris wrote:

 How about this? Using existing keywords, with a rename of "const":
 
 1) final       - rebinding of a value to a name
 2) invariant   - a read-only view of a data structure
 3) constant    - a value that never changes


Actually, that's pretty good too. Getting rid of the keyword "const" 
would definitely highlight that something is different between D's 
const-ness and the const-ness in other (anachronistic ;-) ) languages.

--benji
Mar 16 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
kris wrote:

 How about this? Using existing keywords, with a rename of "const":
 
 1) final       - rebinding of a value to a name


[moved '2)']

 3) constant    - a value that never changes


These two are fine by me.


 2) invariant   - a read-only view of a data structure


No. Just No.
For one thing, the data structure can vary :) : anyone with a mutable 
reference can change the value from under your nose, so "does not vary" 
simply isn't applicable here.
But more importantly, invariant has a very clear and defined meaning in 
computer science. It should not be overloaded like this.
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Frits van Bommel wrote:

 kris wrote:

 How about this? Using existing keywords, with a rename of "const":

 1) final       - rebinding of a value to a name


 [moved '2)']

 3) constant    - a value that never changes


 
 These two are fine by me.
 
  > 2) invariant   - a read-only view of a data structure
 
 No. Just No.
 For one thing, the data structure can vary :) : anyone with a mutable 
 reference can change the value from under your nose, so "does not vary" 
 simply isn't applicable here.
 But more importantly, invariant has a very clear and defined meaning in 
 computer science. It should not be overloaded like this.


Much of the terminological problem is that it's hard to express const's 
imprecision (as opposed to super const's precision) tersely.

One of my ideas was using "const" for truly set in stone, and using 
"const?" to mean that the object may or may not have originated as 
const. But code with question marks everywhere would look odd.


Andrei
Mar 16 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


 
 The problem with 'view' is that it's a noun, while final and const are 
 adjectives. It's very awkward to use 'view':
 
 view int * p = &x; // huh?
 
 Andrei


And 'view' is also probably a very popular name for a variable thanks to 
things like the "Model-View-Controller" paradigm.

http://www.google.com/codesearch?q=view&hl=en&btnG=Search+Code


--bb
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:

 For what it's worth, I like: 'final', 'view', and 'const' the best. 
 They're all short and meaningful, given the intent for each.


 The problem with 'view' is that it's a noun, while final and const are 
 adjectives. It's very awkward to use 'view':

 view int * p = &x; // huh?

 Andrei


 
 And 'view' is also probably a very popular name for a variable thanks to 
 things like the "Model-View-Controller" paradigm.
 
 http://www.google.com/codesearch?q=view&hl=en&btnG=Search+Code


However, viewonly is a possibility that's particularly expressive. As 
much as I'm wary of collapsed words, this is the contender I like the 
most. It's a bit long though, and given that it's also the most heavily 
used, it would lead to long lines.

But, as Walter put it very wisely: addressing immutability is a big 
problem, and syntax is only a fraction of it.


Andrei
Mar 16 2007
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 BTW, you've also mentioned changing "inout" to "ref" instead? That would 
 probably break more code than a renaming of const; I know both Tango and 
 Mango use inout quite a bit, but I'm happy to change those as necessary. 
 Other people likely feel the same way.


Changing inout to ref would be a very long process in several stages:

1) Adding ref as a keyword and documenting its usage
2) Recommending changing usage from 'inout' to 'ref'
3) Removing 'inout' from the documentation
4) Producing a warning on 'inout' with -w switch
5) Deprecating 'inout'
6) Removing 'inout' as keyword

Also, 'inout' is easily greppable, and very likely is unique enough that 
using nothing more than a global search/replace will work.
Mar 16 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 kris wrote:

 BTW, you've also mentioned changing "inout" to "ref" instead? That 
 would probably break more code than a renaming of const; I know both 
 Tango and Mango use inout quite a bit, but I'm happy to change those 
 as necessary. Other people likely feel the same way.


 
 Changing inout to ref would be a very long process in several stages:
 
 1) Adding ref as a keyword and documenting its usage
 2) Recommending changing usage from 'inout' to 'ref'
 3) Removing 'inout' from the documentation
 4) Producing a warning on 'inout' with -w switch
 5) Deprecating 'inout'
 6) Removing 'inout' as keyword
 
 Also, 'inout' is easily greppable, and very likely is unique enough that 
 using nothing more than a global search/replace will work.


I will notice that that process didn't start for the infamous magic 
variable "length". It's still in 
http://digitalmars.com/d/expression.html :o(.

Andrei
Mar 16 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 kris wrote:

 BTW, you've also mentioned changing "inout" to "ref" instead? That 
 would probably break more code than a renaming of const; I know both 
 Tango and Mango use inout quite a bit, but I'm happy to change those 
 as necessary. Other people likely feel the same way.


 
 Changing inout to ref would be a very long process in several stages:
 
 1) Adding ref as a keyword and documenting its usage
 2) Recommending changing usage from 'inout' to 'ref'
 3) Removing 'inout' from the documentation
 4) Producing a warning on 'inout' with -w switch
 5) Deprecating 'inout'
 6) Removing 'inout' as keyword
 
 Also, 'inout' is easily greppable, and very likely is unique enough that 
 using nothing more than a global search/replace will work.


Why not just stop at '1'?   Inout is very descriptive if what you're 
planning to do is modify the input in a way that the caller can see the 
changes.  Just make it a synonym for 'ref'.  And instead of telling 
people not to use it, tell them to use it only when inout behavior is 
the actual intent.  Otherwise use 'const ref'.  And make 'const inout' 
be an error.

But in terms of the syntax tree generated, both 'inout' and 'ref' will 
be 'ref's.

--bb
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 kris wrote:

 BTW, you've also mentioned changing "inout" to "ref" instead? That 
 would probably break more code than a renaming of const; I know both 
 Tango and Mango use inout quite a bit, but I'm happy to change those 
 as necessary. Other people likely feel the same way.


 Changing inout to ref would be a very long process in several stages:

 1) Adding ref as a keyword and documenting its usage
 2) Recommending changing usage from 'inout' to 'ref'
 3) Removing 'inout' from the documentation
 4) Producing a warning on 'inout' with -w switch
 5) Deprecating 'inout'
 6) Removing 'inout' as keyword

 Also, 'inout' is easily greppable, and very likely is unique enough 
 that using nothing more than a global search/replace will work.


 
 Why not just stop at '1'?   Inout is very descriptive if what you're 
 planning to do is modify the input in a way that the caller can see the 
 changes.  Just make it a synonym for 'ref'.  And instead of telling 
 people not to use it, tell them to use it only when inout behavior is 
 the actual intent.  Otherwise use 'const ref'.  And make 'const inout' 
 be an error.


That's very awkward. Exact synonyms fare real bad in all languages I 
know. It's chaff without any nutritional benefit. Everybody would have 
preferred that "=>" in Perl is something different from ",", or that 
template<typename T> and template<class T> would be different things in C++.


Andrei
Mar 16 2007
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 11:48:47 -0700, kris wrote:


 ... but I'm happy to change those as necessary. 
 Other people likely feel the same way.


I am more than happy to change my source code if the result is easier to
read and an improved D.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
kris wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:


 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.



 Then how would you call "value that's not mutable through this alias" 
 in a way that's not going to turn C++ immigrants away?


 
 
 there are explicit names for that sort of thing; "immutable", "readonly" 
 , "view" etc.  Reading through the various replies gives the impression 
 that you're concerned about propogating the broken C++ semantics than 
 ensuring D corrects those faults ;)


No, just no gratuitous incompatibilities and misunderstanding. For 
example, "readonly" reminds some of ROM, which is really immutable. 
Then, "view" is too common a word to steal it as a keyword. Finally, 
"immutable" is again ambiguous.


 I think it's worthwhile ensuring D gets it right instead, and I'll 
 happily change all of Tango to reflect that if necessary. Breaking 
 source-code for a keyword that is currently used rarely is not a 
 problem. Incorrect or dubious/confusing semantics are. It may be 
 worthwhile dumping the "const" keyword altogether, to limit confusion.


You know, that might be a good idea.


 BTW, you've also mentioned changing "inout" to "ref" instead? That would 
 probably break more code than a renaming of const; I know both Tango and 
 Mango use inout quite a bit, but I'm happy to change those as necessary. 
 Other people likely feel the same way.


Thanks, that's good to hear. Dropping inout would be one of the harder 
decisions to make.


Andrei
Mar 16 2007
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 
 Then how would you call "value that's not mutable through this alias" in 
 a way that's not going to turn C++ immigrants away?
 
 Andrei


I have no special love (nor contempt, of course) for C++ immigrants and 
don't really care whether D conforms to their expectations.

I thought the point of D was to fix broken constructs from C++, and most 
C++ programmers I know consider its implementation of const (and 
especially how casting affects const) to be one of the prime offenders.

--benji
Mar 16 2007
next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 12:38:00 -0700, Benji Smith wrote:


 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 
 Then how would you call "value that's not mutable through this alias" in 
 a way that's not going to turn C++ immigrants away?
 
 Andrei


 
 I have no special love (nor contempt, of course) for C++ immigrants and 
 don't really care whether D conforms to their expectations.
 
 I thought the point of D was to fix broken constructs from C++, and most 
 C++ programmers I know consider its implementation of const (and 
 especially how casting affects const) to be one of the prime offenders.


Thank you Benji ... I've been trying to write a response to that but
everything I wrote came out as too abusive or obnoxious. You have nailed it
though.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
prev sibling next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 Then how would you call "value that's not mutable through this alias" 
 in a way that's not going to turn C++ immigrants away?

 Andrei


 
 I have no special love (nor contempt, of course) for C++ immigrants and 
 don't really care whether D conforms to their expectations.


Well, you see - quot capita, tot sententiae. :o) It's not about 
expectations as much as taking the good without the bad, while avoiding 
gratuitous incompatibilities. This is, I understand, high on Walter's 
priority list.


 I thought the point of D was to fix broken constructs from C++, and most 
 C++ programmers I know consider its implementation of const (and 
 especially how casting affects const) to be one of the prime offenders.


We know why C++ const is broken. The fact that it does not mean super 
const is not the reason.


Andrei
Mar 16 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 Then how would you call "value that's not mutable through this alias" 
 in a way that's not going to turn C++ immigrants away?

 Andrei


 
 I have no special love (nor contempt, of course) for C++ immigrants and 
 don't really care whether D conforms to their expectations.
 
 I thought the point of D was to fix broken constructs from C++, and most 
 C++ programmers I know consider its implementation of const (and 
 especially how casting affects const) to be one of the prime offenders.
 
 --benji


Same opinion here. What makes D good is fixing broken constructs from C++.
-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:

 Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" 
 means something other than "value resolved at compile time and 
 immutable at runtime" would be a mistake.


 Then how would you call "value that's not mutable through this alias" 
 in a way that's not going to turn C++ immigrants away?

 Andrei


 I have no special love (nor contempt, of course) for C++ immigrants 
 and don't really care whether D conforms to their expectations.

 I thought the point of D was to fix broken constructs from C++, and 
 most C++ programmers I know consider its implementation of const (and 
 especially how casting affects const) to be one of the prime offenders.

 --benji


 
 Same opinion here. What makes D good is fixing broken constructs from C++.


Same opinion here too.

Andrei
Mar 16 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


I hear you. I've always disliked C++'s mutable const.

The most important thing at this stage is not the keyword, however, but 
getting the design right. Andrei, myself and Bartosz have been to hell 
and back several times over this over the last few months, and have 
filled about two notebooks with scribblings. It's a difficult problem.

There are 3 distinct, and very different, flavors of constant:

1) rebinding of a value to a name
2) a read-only view of a data structure
3) a value that never changes

C++ tries to do all three with one keyword, and makes a confusing hash 
of it.

For the purposes of discussion, and to avoid confusing ourselves, we 
adopted working names of:
1) final
2) const
3) super const

The hard part is to figure out how these 3 interact, how they look & 
feel, how they work with type deduction, type inference, type combining, 
how do we sidestep the clumsiness in C++'s handling of it, etc.

Once that's all done, picking the right keywords is a whole 'nother 
discussion, with several considerations:
1) common use of 'const' in C++, and the expectations and comfort people 
coming from C++ have with it
2) your point above, that const should be constant
3) keyword minimization
4) avoid stepping on commonly used names
5) ease and economy of typing
Mar 16 2007
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Walter Bright wrote:

 There are 3 distinct, and very different, flavors of constant:
 
 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes
 
 C++ tries to do all three with one keyword, and makes a confusing hash 
 of it.
 
 For the purposes of discussion, and to avoid confusing ourselves, we 
 adopted working names of:
 1) final
 2) const
 3) super const


I appreciate the thought you guys have put into it. And the 
implementation sounds exactly right, from a semantic perspective. It's 
just the syntax that's slightly wrong, to me.

Using your mapping above, I'd tweak it slightly to read:

1) final
2) readonly
3) const

On a side note: if the existing proposal was enacted, I think the 
exclamation point would be the most commonly overloaded symbol (possibly 
only competing with * for multiplication, pointer declaration, and 
pointer dereferencing), while other symbols (like ^ or %) are currently 
only single-purpose. Any overriding philosophy on the usage and 
overloading of symbol characters?

--benji
Mar 16 2007
parent Walter Bright <newshound digitalmars.com> writes:
Benji Smith wrote:

 Any overriding philosophy on the usage and
 overloading of symbol characters?


Not that I can think of.
Mar 16 2007
prev sibling next sibling parent kris <foo bar.com> writes:
Walter Bright wrote:

 Benji Smith wrote:
 

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 
 
 I hear you. I've always disliked C++'s mutable const.
 
 The most important thing at this stage is not the keyword, however, but 
 getting the design right. Andrei, myself and Bartosz have been to hell 
 and back several times over this over the last few months, and have 
 filled about two notebooks with scribblings. It's a difficult problem.
 
 There are 3 distinct, and very different, flavors of constant:
 
 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes
 
 C++ tries to do all three with one keyword, and makes a confusing hash 
 of it.
 
 For the purposes of discussion, and to avoid confusing ourselves, we 
 adopted working names of:
 1) final
 2) const
 3) super const
 
 The hard part is to figure out how these 3 interact, how they look & 
 feel, how they work with type deduction, type inference, type combining, 
 how do we sidestep the clumsiness in C++'s handling of it, etc.
 
 Once that's all done, picking the right keywords is a whole 'nother 
 discussion, with several considerations:
 1) common use of 'const' in C++, and the expectations and comfort people 
 coming from C++ have with it
 2) your point above, that const should be constant
 3) keyword minimization
 4) avoid stepping on commonly used names
 5) ease and economy of typing



Glad to hear you guys are open to considerations. For purpose of 
discussion, you /could/ adopt the following instead:

1) final       - rebinding of a value to a name
2) view        - a read-only view of a data structure
3) constant    - a value that never changes

Not only is that pretty clear, it also dumps the "const" keyword that 
may otherwise cause some "adjustment" for C++ people
Mar 16 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 
 I hear you. I've always disliked C++'s mutable const.
 
 The most important thing at this stage is not the keyword, however, but 
 getting the design right. Andrei, myself and Bartosz have been to hell 
 and back several times over this over the last few months, and have 
 filled about two notebooks with scribblings. It's a difficult problem.


I very much agree.  But with little information about how these new 
flavors of const will work, it seems we're mostly stuck debating how 
they will look :-)  I'd welcome discussing the former issue, but I 
suspect that anything which is said here will have already been 
discussed between you three.


 There are 3 distinct, and very different, flavors of constant:
 
 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes



means pointers and class handles.  Further, I don't think I've ever 
found a need for this particular class of immutability in C++.  How 
often does it really matter whether someone can reassign a pointer?



this much thought, but is it truly necessary to have two separate 

is there a perceived value here from a user perspective?

Please don't get me wrong, I very much appreciate the desire for a 
comprehensive solution, but at the same time I wonder whether the 
struggle to integrate three fairly diverse concepts might be part of the 
reason why this all seems so complicated.  Are they all truly necessary? 
  And is it necessary to distinguish all three by separate keywords?


 C++ tries to do all three with one keyword, and makes a confusing hash 
 of it.


Agreed, despite how the above likely sounds.


Sean
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" means 
 something other than "value resolved at compile time and immutable at 
 runtime" would be a mistake.


 I hear you. I've always disliked C++'s mutable const.

 The most important thing at this stage is not the keyword, however, 
 but getting the design right. Andrei, myself and Bartosz have been to 
 hell and back several times over this over the last few months, and 
 have filled about two notebooks with scribblings. It's a difficult 
 problem.


 
 I very much agree.  But with little information about how these new 
 flavors of const will work, it seems we're mostly stuck debating how 
 they will look :-)  I'd welcome discussing the former issue, but I 
 suspect that anything which is said here will have already been 
 discussed between you three.
 

 There are 3 distinct, and very different, flavors of constant:

 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes


 

 means pointers and class handles.





 Further, I don't think I've ever 
 found a need for this particular class of immutability in C++.  How 
 often does it really matter whether someone can reassign a pointer?


Very important. Often you want to bind a pointer to something and make 
sure nothing can change that.





No, because the value may embed pointers that you want to pass to 
functions. Sorry for sounding dismissive, but we've been all of these 
dead alleys for so long, it's all green codes: I can see the damn Matrix 
now. Blonde, brunette, const, final...







const. Essentially "const" loses a little of the precision that "super 
const" has.


 I haven't given 
 this much thought, but is it truly necessary to have two separate 



It's not! That's what I tried to do all along...


 Is this to aid the compiler in optimizing, or 
 is there a perceived value here from a user perspective?


It will be absolutely essential for the well-definedness of 
functional-style threads.


 Please don't get me wrong, I very much appreciate the desire for a 
 comprehensive solution, but at the same time I wonder whether the 
 struggle to integrate three fairly diverse concepts might be part of the 
 reason why this all seems so complicated.  Are they all truly necessary? 


I'd think so.


  And is it necessary to distinguish all three by separate keywords?


It's not necessary :o).


Andrei
Mar 16 2007
parent reply Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" 
 means something other than "value resolved at compile time and 
 immutable at runtime" would be a mistake.


 I hear you. I've always disliked C++'s mutable const.

 The most important thing at this stage is not the keyword, however, 
 but getting the design right. Andrei, myself and Bartosz have been to 
 hell and back several times over this over the last few months, and 
 have filled about two notebooks with scribblings. It's a difficult 
 problem.


 I very much agree.  But with little information about how these new 
 flavors of const will work, it seems we're mostly stuck debating how 
 they will look :-)  I'd welcome discussing the former issue, but I 
 suspect that anything which is said here will have already been 
 discussed between you three.


 There are 3 distinct, and very different, flavors of constant:

 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes



 means pointers and class handles.


 



Could you please provide an example?


 Further, I don't think I've ever found a need for this particular 
 class of immutability in C++.  How often does it really matter whether 
 someone can reassign a pointer?


 
 Very important. Often you want to bind a pointer to something and make 
 sure nothing can change that.


Perhaps this should be rewritten as "often one wants to..."  I just said 
that I have never felt a need for this :-)  Of the times where I've used 
this feature in C/C++, I think every single time has been simply out of 
diligence rather than because there was any risk of the pointer actually 
being reassigned.  A pertinent point to me is that D uses pass-by-value 
so the chance of a reference being silently reassigned "somewhere in the 
program" is typically almost nil.  About the only place where this is a 
real risk is with global variables, and since free functions support the 
property syntax, the programmer has a ready option to prevent such a 
reassignment from happening.  Besides, free globals are bad programming 
style anyway.





 
 No, because the value may embed pointers that you want to pass to 
 functions. Sorry for sounding dismissive, but we've been all of these 
 dead alleys for so long, it's all green codes: I can see the damn Matrix 
 now. Blonde, brunette, const, final...


That's fine.  You may have been down all these roads before, but I 
haven't.  I'm mostly asking to gain a better understanding of some of 
the background.





 

 const. Essentially "const" loses a little of the precision that "super 
 const" has.






 I haven't given this much thought, but is it truly necessary to have 



 
 It's not! That's what I tried to do all along...


(see below)


 Is this to aid the compiler in optimizing, or is there a perceived 
 value here from a user perspective?


 
 It will be absolutely essential for the well-definedness of 
 functional-style threads.


Okay, that's what I figured, though this seems to contradict what you 
said above.  So in essence, "super const" is actually necessary in some 
situations to indicate to the programmer that the data he is 
manipulating is truly immutable.  I almost feel like this feature should 
exist separately from the type mechanism, so there was a way to test for 
this instead.


  And is it necessary to distinguish all three by separate keywords?


 
 It's not necessary :o).




for both, but I very much do not want all of this to become a confusing 
mess when applied to actual code.


Sean
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 Benji Smith wrote:

 I should also add that, in my opinion, any design where "const" 
 means something other than "value resolved at compile time and 
 immutable at runtime" would be a mistake.


 I hear you. I've always disliked C++'s mutable const.

 The most important thing at this stage is not the keyword, however, 
 but getting the design right. Andrei, myself and Bartosz have been 
 to hell and back several times over this over the last few months, 
 and have filled about two notebooks with scribblings. It's a 
 difficult problem.


 I very much agree.  But with little information about how these new 
 flavors of const will work, it seems we're mostly stuck debating how 
 they will look :-)  I'd welcome discussing the former issue, but I 
 suspect that anything which is said here will have already been 
 discussed between you three.


 There are 3 distinct, and very different, flavors of constant:

 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes



 means pointers and class handles.





 
 Could you please provide an example?


final int x = 42;


 Further, I don't think I've ever found a need for this particular 
 class of immutability in C++.  How often does it really matter 
 whether someone can reassign a pointer?


 Very important. Often you want to bind a pointer to something and make 
 sure nothing can change that.


 
 Perhaps this should be rewritten as "often one wants to..."  I just said 
 that I have never felt a need for this :-)  Of the times where I've used 
 this feature in C/C++, I think every single time has been simply out of 
 diligence rather than because there was any risk of the pointer actually 
 being reassigned.  A pertinent point to me is that D uses pass-by-value 
 so the chance of a reference being silently reassigned "somewhere in the 
 program" is typically almost nil.  About the only place where this is a 
 real risk is with global variables, and since free functions support the 
 property syntax, the programmer has a ready option to prevent such a 
 reassignment from happening.  Besides, free globals are bad programming 
 style anyway.


I think "final" is mostly useful in class and struct members.





 No, because the value may embed pointers that you want to pass to 
 functions. Sorry for sounding dismissive, but we've been all of these 
 dead alleys for so long, it's all green codes: I can see the damn 
 Matrix now. Blonde, brunette, const, final...


 
 That's fine.  You may have been down all these roads before, but I 
 haven't.  I'm mostly asking to gain a better understanding of some of 
 the background.
 





 const. Essentially "const" loses a little of the precision that "super 
 const" has.


 







 I haven't given this much thought, but is it truly necessary to have 



 It's not! That's what I tried to do all along...


 
 (see below)
 

 Is this to aid the compiler in optimizing, or is there a perceived 
 value here from a user perspective?


 It will be absolutely essential for the well-definedness of 
 functional-style threads.


 
 Okay, that's what I figured, though this seems to contradict what you 
 said above.  So in essence, "super const" is actually necessary in some 
 situations to indicate to the programmer that the data he is 
 manipulating is truly immutable.  I almost feel like this feature should 
 exist separately from the type mechanism, so there was a way to test for 
 this instead.


Then you can't prove correctness statically.


  And is it necessary to distinguish all three by separate keywords?


 It's not necessary :o).


 


 for both, but I very much do not want all of this to become a confusing 
 mess when applied to actual code.


Much anything else would become a mess when applied to actual code. I 
think we discussed about two dozens of schemes. They all looked great on 
paper, at least at first blush. They all did miserably during a test drive.


Andrei
Mar 16 2007
parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 There are 3 distinct, and very different, flavors of constant:

 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes



 means pointers and class handles.





 Could you please provide an example?


 
 final int x = 42;


I must be missing something here.  I expected this to be the point of 
'const'.  In C++ parlance:

int const * const val = 0;
       ^       ^
       |       |



 I think "final" is mostly useful in class and struct members.


Seems reasonable I suppose.  Will there be any change to "final" as it 
exists now in D, or is this simply an extension of its meaning?


 Okay, that's what I figured, though this seems to contradict what you 
 said above.  So in essence, "super const" is actually necessary in 
 some situations to indicate to the programmer that the data he is 
 manipulating is truly immutable.  I almost feel like this feature 
 should exist separately from the type mechanism, so there was a way to 
 test for this instead.


 
 Then you can't prove correctness statically.


Argh.  Good point.


 So it sounds like it truly isn't necessary to separately distinguish 

 need for both, but I very much do not want all of this to become a 
 confusing mess when applied to actual code.


 
 Much anything else would become a mess when applied to actual code. I 
 think we discussed about two dozens of schemes. They all looked great on 
 paper, at least at first blush. They all did miserably during a test drive.


Well... darnit :-)


Sean
Mar 16 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 For the purposes of discussion, and to avoid confusing ourselves, we 
 adopted working names of:
 1) final
 2) const
 3) super const


How about taking Andrei's observation about extern(C) and scope(exit) 
and letting const have a modifier?

1) final
2) const
3) const(strong)

or something like that?  I guess the problem is that const(something) 
already has a meaning if it's something like const(int*).

--bb
Mar 16 2007
prev sibling parent Geoff Carlton <gcarlton iinet.net.au> writes:
Walter Bright wrote:

 
 There are 3 distinct, and very different, flavors of constant:
 
 1) rebinding of a value to a name
 2) a read-only view of a data structure
 3) a value that never changes
 
 C++ tries to do all three with one keyword, and makes a confusing hash 
 of it.
 
 For the purposes of discussion, and to avoid confusing ourselves, we 
 adopted working names of:
 1) final
 2) const
 3) super const
 


Well, I'm a C++ programmer and I think the last two are much more 
confusing than "readonly" and a different "const".  If they keywords are 
simple and intuitive then the learning curve will be quick.  Can't get 
much better than "readonly" (I can't write to this data, but it may 
change) and "const" (the data will not change).

Consider these two statements:

The problem with C++ "const" is that it isn't really constant.  D fixes 
this by having "readonly" for an immutable view, and "const" actually 
meaning that the data is guaranteed not going to change.

The problem with C++ "const" is that it isn't really constant.  D's 
"const" is also not really constant, but "super const" has been added 
for data that is guaranteed not going to change.

Also, I am slightly confused why examples of final have been given with 
value types:
   final int x = 3;
But x can never be rebound as it isn't a reference - what the user 
really means is the value never changes, therefore keyword (3) rather 
than keyword (1) seems appropriate here.



 The hard part is to figure out how these 3 interact, how they look & 
 feel, how they work with type deduction, type inference, type combining, 
 how do we sidestep the clumsiness in C++'s handling of it, etc.
 


Regardless of syntax, I would love to hear the advantages of the 
proposed system.  It seems the really big change is the addition of (3), 
but I can't quite see how you could create complex data sets that are 
guaranteed constant apart from using "trust me" casts.

For example, an function may take a data set as super const, therefore 
making optimisations.  But the creation of such a data set (say a map of 
ints to an array of strings, or a graph of nodes) may well be done at 
runtime, such as loading it from a file.  How do you "pin" runtime data 
to get a super constant type?

Can you even create super const data using custom classes?  Must 
everything be done in the constructor?  What about pointers to non-owned 
non-constant data, such as back to an owner object?  I'm intrigued.  Any 
chance of posting some "behind the scenes" with the discussion and 
resolution to the issues you guys have grappled with?
Mar 17 2007
prev sibling next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)

 Andrei


 
 Really? I'd think super const would be used all the time. Anywhere a 
 class has some invariant field, it'll probably be expressed as super 
 const (if I'm understanding correctly that super const is the equivalent 
 of #define constants in C++ or static final constants in Java).


No. super const deals with pointers and transitivity. Final deals with 
non-rebindable symbols. I'd be hard pressed to think of many examples 
where class members are transitively immutable.


 Let me join the ranks of those who hate both versions of the new syntax. 
  const! looks either like a template or like "not const". You guys may 
 think you're saving a keyword, and that might be technically correct 
 from the perspective of the parser.


The parser has zilch to do with it.


 But, for the perspective of the D 
 developer, it still looks like you've introduced a new keyword, but it's 
 a keyword that's A) nearly identical to another keyword, and B) contains 
 a symbol. Ugh. I really. Really. Really. Hate it.


Can't help. For any given feature, there will be people who hate it. 
Usually they are also the most vocal :o).


 Using "super const" is also annoying because all of the other storage 
 classes use a single keyword. Now we've got this weird case that uses 
 two keywords. And the word "super" is now overloaded in two completely 
 unrelated concepts.


So what? Don't we use words in natural language that are polysemous too? 
As long as the context makes it unambiguous, great.


 (By the way, I don't like "static if" either. I think the right choice 
 would have been #if, #foreach, etc. And I think C++ made a mistake by 
 defining "long long" and "double double" types as well. Presumably, that 
 saved some keywords, but we'd all have been better off if the types were 
 defined as int8, int16, int32, int64, float32, float64, etc).


You're making my point exactly. I love static if, and don't like #if. 
Again: for each feature, there will be people who like it and hate it :o).


 I vote for "readonly" and "const". Anything else seems like a mistake.


Which is which? How would you have people distinguish them without 
running to the manual? How would you explain C++ immigrants that const 
is actually readonly, and there is a const, but that const means 
something else than their const?


Andrei
Mar 16 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I vote for "readonly" and "const". Anything else seems like a mistake.


 
 Which is which? How would you have people distinguish them without 
 running to the manual? How would you explain C++ immigrants that const 
 is actually readonly, and there is a const, but that const means 
 something else than their const?


How would you have people distinguish char/wchar/dchar without running 
to the Unicode standard to see which characters they can hold in a 
single unit?
Or short/int/long or float/double/real without running to the standard 
to look up the ranges and precision of those data types?

How would you explain to the average person from the 
Netherlands/Estonia/Finland/Germany/Slovakia[1] 'auto' doesn't have 
anything to do with transportation?
How would you explain to Dutchmen that 'long' doesn't have anything to 
do with breathing air? (Hint for all you foreigners out here: the Dutch 
word 'long' translates to 'lung' :P )

Some things are somewhat arbitrary conventions.
When you learn a new language, some words will mean different things, 
with other words that have the meaning you're used to.
It happens ;).

[1]: See http://dictionary.reference.com/search?q=car , specifically the 
first set of translations, roughly halfway down the page




Seriously though:
"readonly" would mean that you (meaning any code that can access the 
symbol so declared) can only read data referenced through it, but 
someone else _may_ be able to write to it[2].
"const" would mean it's just that: constant. *Nobody* can write to it.
Seems pretty easy to explain to me.

The only caveat I see is that "readonly" would mean the object itself 
can still be modified, as opposed to final. I don't see how calling it 
"const" would fix that, though.


[2]: Or of course that same code may be able to write to it, if for 
whatever reason it also has access to a mutable reference to the same data.
Mar 16 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Frits van Bommel wrote:

 Seriously though:
 "readonly" would mean that you (meaning any code that can access the 
 symbol so declared) can only read data referenced through it, but 
 someone else _may_ be able to write to it[2].


My perception of that is different. I used to do embedded systems, and
'readonly' means the data went into ROM. Also, marking a page in a 
virtual memory system as 'readonly' means that nobody can modify it.

'super const' at least has the connotation of being "constant, this time 
we mean it".
Mar 16 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:

 Frits van Bommel wrote:

 Seriously though:
 "readonly" would mean that you (meaning any code that can access the 
 symbol so declared) can only read data referenced through it, but 
 someone else _may_ be able to write to it[2].


 
 My perception of that is different. I used to do embedded systems, and
 'readonly' means the data went into ROM. Also, marking a page in a 
 virtual memory system as 'readonly' means that nobody can modify it.


Perhaps, but my perception of 'const' is different ;). Particularly, it 
seems to be short for "constant", which is therefore what it should 
mean. Not "*you* can't change this, but someone else might anyway".

Oh, and on x86 (and amd64) processors the operating system is allowed to 
write to 'readonly'[1] pages unless it sets the WP (Write-Protect) bit 
in system register CR0. Note: as this bit is *off* by default, it needs 
to be explicitly turned on by the OS.


[1] Well, technically they're not really readonly, it's more like 
non-writable (since the appropriate bit must be 1 on all levels of the 
paging data structures to get a writable page) but that's heading /even 
faster/ into the realm of nitpicking :).



 'super const' at least has the connotation of being "constant, this time 
 we mean it".


Wouldn't it be better if 'const' just _meant what it said_ in the first 
place? :P
Mar 16 2007
parent reply Sean Kelly <sean f4.ca> writes:
Frits van Bommel wrote:

 Walter Bright wrote:

 Frits van Bommel wrote:

 Seriously though:
 "readonly" would mean that you (meaning any code that can access the 
 symbol so declared) can only read data referenced through it, but 
 someone else _may_ be able to write to it[2].


 My perception of that is different. I used to do embedded systems, and
 'readonly' means the data went into ROM. Also, marking a page in a 
 virtual memory system as 'readonly' means that nobody can modify it.


 
 Perhaps, but my perception of 'const' is different ;). Particularly, it 
 seems to be short for "constant", which is therefore what it should 
 mean. Not "*you* can't change this, but someone else might anyway".
 
 Oh, and on x86 (and amd64) processors the operating system is allowed to 
 write to 'readonly'[1] pages unless it sets the WP (Write-Protect) bit 
 in system register CR0. Note: as this bit is *off* by default, it needs 
 to be explicitly turned on by the OS.


So *that's* why Win32 doesn't complain when constant data is modified 
and pretty much every other OS does.  Good to know.

By the way... I feel the same about the meaning of 'const'.  On some 
level I still even think that const-by-default is the correct choice, 
but now that D has hit 1.0 that will be a much harder sell.


Sean
Mar 16 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Frits van Bommel wrote:

 Walter Bright wrote:




[snip]

 'readonly' means the data went into ROM. Also, marking a page in a 
 virtual memory system as 'readonly' means that nobody can modify it.






[snip]

 Oh, and on x86 (and amd64) processors the operating system is allowed 
 to write to 'readonly'[1] pages unless it sets the WP (Write-Protect) 
 bit in system register CR0. Note: as this bit is *off* by default, it 
 needs to be explicitly turned on by the OS.


 
 So *that's* why Win32 doesn't complain when constant data is modified 
 and pretty much every other OS does.  Good to know.


No I don't think so. The 'WP' bit only applies to kernel-level (ring 
0-2) code. Ring 3 code (i.e. normal user-level code) can never write 
into "readonly" pages. The only explanation I can think of for Win32 
allowing writes into a programs read-only data is that the pages aren't 
marked "readonly" at all for some reason.

Unless of course user-level code is ran somewhere in ring 0-2, but I 
don't think even Windows would do something so stupidly insecure: that 
would allow user-level code to read and write anywhere in kernel space, 
barring segment limits.

(I didn't say Microsoft instead of Windows above, since Microsoft's 
research division is experimenting with a .NET based OS that *does* run 
everything in ring 0. However, that uses a different mechanism to ensure 
safety: programs are checked for type-safety before being allowed to 
run. That's not really feasible for traditional machine-code based OSs 
though...)
Mar 16 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I vote for "readonly" and "const". Anything else seems like a mistake.


 
 Which is which? How would you have people distinguish them without 
 running to the manual? How would you explain C++ immigrants that const 
 is actually readonly, and there is a const, but that const means 
 something else than their const?


Hospitality to C++ immigrants is definitely important. But since C++ 
const is broken, there's inevitably going to be some culture shock.

I think we're OK as long as D const is more restrictive than C++ const
  -- so that writing C++ code in D will either work the same as in C++, 
or fail to compile.
And I don't think that the confusion exists for anyone other than C++ 
programmers.

Don
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Don Clugston wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 I vote for "readonly" and "const". Anything else seems like a mistake.


 Which is which? How would you have people distinguish them without 
 running to the manual? How would you explain C++ immigrants that const 
 is actually readonly, and there is a const, but that const means 
 something else than their const?


 
 Hospitality to C++ immigrants is definitely important. But since C++ 
 const is broken, there's inevitably going to be some culture shock.


Let me say it again: we know why it's broken. We will provide a fixed 
equivalent, not something entirely different. It's only natural to call 
the fixed equivalent the same.


 I think we're OK as long as D const is more restrictive than C++ const
  -- so that writing C++ code in D will either work the same as in C++, 
 or fail to compile.
 And I don't think that the confusion exists for anyone other than C++ 
 programmers.


Which are in the millions :o).


Andrei
Mar 16 2007
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Really? I'd think super const would be used all the time. Anywhere a 
 class has some invariant field, it'll probably be expressed as super 
 const (if I'm understanding correctly that super const is the 
 equivalent of #define constants in C++ or static final constants in 
 Java).


 
 No. super const deals with pointers and transitivity. Final deals with 
 non-rebindable symbols. I'd be hard pressed to think of many examples 
 where class members are transitively immutable.


Aha. In that case, what would you think of the declaration:

   super const int MY_CONSTANT = 6;

Since a value type doesn't have any pointers, it wouldn't make any sense 
to apply super-constness to it, right? Should that be a compiler error?

--benji
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Really? I'd think super const would be used all the time. Anywhere a 
 class has some invariant field, it'll probably be expressed as super 
 const (if I'm understanding correctly that super const is the 
 equivalent of #define constants in C++ or static final constants in 
 Java).


 No. super const deals with pointers and transitivity. Final deals with 
 non-rebindable symbols. I'd be hard pressed to think of many examples 
 where class members are transitively immutable.


 
 Aha. In that case, what would you think of the declaration:
 
   super const int MY_CONSTANT = 6;
 
 Since a value type doesn't have any pointers, it wouldn't make any sense 
 to apply super-constness to it, right? Should that be a compiler error?


This should be a compiler error.

Andrei
Mar 16 2007
parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 Aha. In that case, what would you think of the declaration:

   super const int MY_CONSTANT = 6;

 Since a value type doesn't have any pointers, it wouldn't make any 
 sense to apply super-constness to it, right? Should that be a compiler 
 error?


 
 This should be a compiler error.
 
 Andrei


Cool. That's what I'd expect.

Maybe rather than "super const", you could use "ref const" or "const*" 
or something that directly indicates that this form of constantness 
applies to the pointers rather than the values. If you use "ref" as a 
replacement for "inout", then the "ref" keyword would get some re-use.

Actually, though, I kind of like the idea of "const*"

   // Create a constant pointer from a mutable pointer
   const* int* myPointer = pMutableInt;

   // Or maybe like this:
   *const int* myPointer = pMutableInt;

What do you think of that? At least the asterisk provides a better clue 
to the functionality of the construct than an exclamation point would.

--benji
Mar 16 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 We've shoved keywords like "readonly" and "view" for a while, and 
 they just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be 
 fine to just encode it as the mildly verbose "super const". In fact, 
 it's shorter than "keepyourgrubbyhandsoff". :o)


 Really? I'd think super const would be used all the time. Anywhere a 
 class has some invariant field, it'll probably be expressed as super 
 const (if I'm understanding correctly that super const is the 
 equivalent of #define constants in C++ or static final constants in 
 Java).


 
 No. super const deals with pointers and transitivity. Final deals with 
 non-rebindable symbols. I'd be hard pressed to think of many examples 
 where class members are transitively immutable.


Well this explains a lot.  I'd misunderstood as well.


Sean
Mar 16 2007
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 09:55:15 -0700, Benji Smith wrote:


 Andrei Alexandrescu (See Website For Email) wrote:

 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)
 
 Andrei


 
 Really? I'd think super const would be used all the time. Anywhere a 
 class has some invariant field, it'll probably be expressed as super 
 const (if I'm understanding correctly that super const is the equivalent 
 of #define constants in C++ or static final constants in Java).
 
 Let me join the ranks of those who hate both versions of the new syntax. 
   const! looks either like a template or like "not const". You guys may 
 think you're saving a keyword, and that might be technically correct 
 from the perspective of the parser. But, for the perspective of the D 
 developer, it still looks like you've introduced a new keyword, but it's 
 a keyword that's A) nearly identical to another keyword, and B) contains 
 a symbol. Ugh. I really. Really. Really. Hate it.
 
 Using "super const" is also annoying because all of the other storage 
 classes use a single keyword. Now we've got this weird case that uses 
 two keywords. And the word "super" is now overloaded in two completely 
 unrelated concepts.
 
 (By the way, I don't like "static if" either. I think the right choice 
 would have been #if, #foreach, etc. And I think C++ made a mistake by 
 defining "long long" and "double double" types as well. Presumably, that 
 saved some keywords, but we'd all have been better off if the types were 
 defined as int8, int16, int32, int64, float32, float64, etc).
 
 I vote for "readonly" and "const". Anything else seems like a mistake.
 
 --benji


Well expressed. My think is almost 100% aligned with these thoughts above.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
prev sibling parent reply "Joel C. Salomon" <JoelCSalomon Gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)


How about “const const”?  No new keywords, no reuse of keywords in 
disparate contexts, and equally noticeable to the eye.

--Joel
Mar 16 2007
next sibling parent Dan <murpsoft hotmail.com> writes:
 How about “const const”?  No new keywords, no reuse of keywords in 
 disparate contexts, and equally noticeable to the eye.
 
 --Joel


Noticeable alright!  I can't even type those characters.  : D
Mar 16 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Joel C. Salomon wrote:

 Andrei Alexandrescu (See Website For Email) wrote:
 

 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)


 
 
 How about “const const”?  No new keywords, no reuse of keywords in 
 disparate contexts, and equally noticeable to the eye.
 
 --Joel


The whole things about adding *more* constantness to const screams one 
thing very loudly: the applicability of the word "const", in this 
context, is borked :)
Mar 16 2007
parent reply Benji Smith <dlanguage benjismith.net> writes:
kris wrote:

 Joel C. Salomon wrote:

 Andrei Alexandrescu (See Website For Email) wrote:


 We've shoved keywords like "readonly" and "view" for a while, and 
 they just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be 
 fine to just encode it as the mildly verbose "super const". In fact, 
 it's shorter than "keepyourgrubbyhandsoff". :o)



 How about “const const”?  No new keywords, no reuse of keywords in 
 disparate contexts, and equally noticeable to the eye.

 --Joel


 
 The whole things about adding *more* constantness to const screams one 
 thing very loudly: the applicability of the word "const", in this 
 context, is borked :)


Bingo. It's like trying to describe something as "impossible 
impossible". If the first usage of the word didn't really convey 
impossibility, then you were using the wrong word to begin with.

--b
Mar 16 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 kris wrote:

 Joel C. Salomon wrote:

 Andrei Alexandrescu (See Website For Email) wrote:


 We've shoved keywords like "readonly" and "view" for a while, and 
 they just added more confusion than cleared, at a high cost. If (as 
 I suspect) super const appears relatively infrequently, it might be 
 fine to just encode it as the mildly verbose "super const". In fact, 
 it's shorter than "keepyourgrubbyhandsoff". :o)



 How about “const const”?  No new keywords, no reuse of keywords in 
 disparate contexts, and equally noticeable to the eye.

 --Joel


 The whole things about adding *more* constantness to const screams one 
 thing very loudly: the applicability of the word "const", in this 
 context, is borked :)


 
 Bingo. It's like trying to describe something as "impossible 
 impossible". If the first usage of the word didn't really convey 
 impossibility, then you were using the wrong word to begin with.


You're "dead dead" right! :o)

Andrei
Mar 16 2007
parent Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 14:25:36 -0700, Andrei Alexandrescu (See Website For
Email) wrote:



 Bingo. It's like trying to describe something as "impossible 
 impossible". If the first usage of the word didn't really convey 
 impossibility, then you were using the wrong word to begin with.


 
 You're "dead dead" right! :o)


Reminds me a bit of the joke ...

Teacher: Two negatives imply a positive ... eg. 'not bad' is 'good'.
         But two positives never imply a negative.

Student: Yeah ... right, whatever.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Benji Smith wrote:

 Bingo. It's like trying to describe something as "impossible 
 impossible". If the first usage of the word didn't really convey 
 impossibility, then you were using the wrong word to begin with.


Reminds me of the old assembler program:

	foo:
		MOV EAX, 3
		CALL BAR
		HALT		; stop the program
		HALT		; if skidding
Mar 16 2007
next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 Benji Smith wrote:
 

 Bingo. It's like trying to describe something as "impossible 
 impossible". If the first usage of the word didn't really convey 
 impossibility, then you were using the wrong word to begin with.


 
 
 Reminds me of the old assembler program:
 
     foo:
         MOV EAX, 3
         CALL BAR
         HALT        ; stop the program
         HALT        ; if skidding


LOL
Mar 16 2007
parent Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Walter Bright wrote:

 Benji Smith wrote:


 Bingo. It's like trying to describe something as "impossible 
 impossible". If the first usage of the word didn't really convey 
 impossibility, then you were using the wrong word to begin with.



 Reminds me of the old assembler program:

     foo:
         MOV EAX, 3
         CALL BAR
         HALT        ; stop the program
         HALT        ; if skidding


 
 LOL


You know those teenagers with the overclocked CPUs...
Mar 16 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Benji Smith wrote:

 Bingo. It's like trying to describe something as "impossible 
 impossible". If the first usage of the word didn't really convey 
 impossibility, then you were using the wrong word to begin with.


 
 Reminds me of the old assembler program:
 
     foo:
         MOV EAX, 3
         CALL BAR
         HALT        ; stop the program
         HALT        ; if skidding


LOL
Mar 16 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Joel C. Salomon wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 We've shoved keywords like "readonly" and "view" for a while, and they 
 just added more confusion than cleared, at a high cost. If (as I 
 suspect) super const appears relatively infrequently, it might be fine 
 to just encode it as the mildly verbose "super const". In fact, it's 
 shorter than "keepyourgrubbyhandsoff". :o)


 
 How about “const const”?  No new keywords, no reuse of keywords in 
 disparate contexts, and equally noticeable to the eye.


It was on the plate briefly. Probably it would be an uphill battle to 
convince people to enjoy it.

Andrei
Mar 16 2007
parent "Joel C. Salomon" <JoelCSalomon Gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 How about “const const”?  No new keywords, no reuse of keywords in 
 disparate contexts, and equally noticeable to the eye.


 
 It was on the plate briefly. Probably it would be an uphill battle to 
 convince people to enjoy it.


I’m still kinda shaky on the question of why the various extra 
specifiers are needed.  If a variable is being declared “const” ought to 
mean nobody can change it, if it’s a function parameter it’s a promise 
that the function won’t change it.  How vital is it that the language 
express “put this in read-only memory” as opposed to “don’t put this in 
read-only memory, but complain if I try to change it”?  Why should a 
function care if it got a pointer to read-only memory or if it just 
promised not to alter the value?

For numeric constants that don’t need addresses, I’d suggest “define” 
rather than “final”, as in:
	define float PI = 3.14159;
If the “#if” syntax for “static if” is adopted, I might even suggest 
“#define”, just to make it clear that something is happening at 
compile-time rather than run-time.

--Joel
Mar 17 2007
prev sibling next sibling parent reply janderson <askme me.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 

 
 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
Mar 16 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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 ;) )
Mar 16 2007
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
janderson 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);

 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 


 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.


The damndest thing is that const! (as well as const) _is_ a template: 
it's a type constructor that takes another type as an argument and 
returns a type.

Andrei
Mar 16 2007
prev sibling next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Fri, 16 Mar 2007 00:16:48 +0300, Andrei Alexandrescu (See Website For=
  =

Email) <SeeWebsiteForEmail erdani.org> wrote:


 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 t=


he  =


 storage addressed indirectly by it (transitively);

 c) "superconst" - denoted as "const!" or "super const": type qualifier=


  =


 meaning that the data is genuinely unmodifiable.


Great!

What about the influence of this storage classes on class method's  =

signatures? Is this will be in D:

class Data { ... }

class Container {
   // non-const access to data.
   Data data() { ... }
   // const access to data.
   const Data data() const { ... }
}

void useContainer( const Container c ) {
   auto d =3D c.data(); // the type of d is 'const Data'.
   ...
}

?

-- =

Regards,
Yauheni Akhotnikau
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
eao197 wrote:

 On Fri, 16 Mar 2007 00:16:48 +0300, Andrei Alexandrescu (See Website For 
 Email) <SeeWebsiteForEmail erdani.org> wrote:
 

 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.


 
 Great!
 
 What about the influence of this storage classes on class method's 
 signatures? Is this will be in D:
 
 class Data { ... }
 
 class Container {
   // non-const access to data.
   Data data() { ... }
   // const access to data.
   const Data data() const { ... }
 }
 
 void useContainer( const Container c ) {
   auto d = c.data(); // the type of d is 'const Data'.
   ...
 }
 
 ?


Yes, that's part of the plan. Moreover, you'll likely have the ability 
to define const-transporting methods (methods that look identical but 
only need to pass the const of the object out to the return value) only 
once. This has been a source of annoyance in certain C++ idioms.


Andrei
Mar 16 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Fri, 16 Mar 2007 12:43:19 +0300, Andrei Alexandrescu (See Website For  
Email) <SeeWebsiteForEmail erdani.org> wrote:


 Yes, that's part of the plan. Moreover, you'll likely have the ability  
 to define const-transporting methods (methods that look identical but  
 only need to pass the const of the object out to the return value) only  
 once. This has been a source of annoyance in certain C++ idioms.


Thanks, I'm glad to hear that!

It seems that D with this storage classes and const-transporting methods  
will be almost different D, may be D 2.0 :)

-- 
Regards,
Yauheni Akhotnikau
Mar 16 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
eao197 wrote:

 On Fri, 16 Mar 2007 12:43:19 +0300, Andrei Alexandrescu (See Website For 
 Email) <SeeWebsiteForEmail erdani.org> wrote:
 

 Yes, that's part of the plan. Moreover, you'll likely have the ability 
 to define const-transporting methods (methods that look identical but 
 only need to pass the const of the object out to the return value) 
 only once. This has been a source of annoyance in certain C++ idioms.


 
 Thanks, I'm glad to hear that!
 
 It seems that D with this storage classes and const-transporting methods 
 will be almost different D, may be D 2.0 :)


Actually, this is exactly true. D 2.0.

Andrei
Mar 16 2007
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
eao197 wrote:


 It seems that D with this storage classes and const-transporting 
 methods  will be almost different D, may be D 2.0 :)


Or perhaps it should be called D++ ?

--anders
Mar 16 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Fri, 16 Mar 2007 15:12:09 +0300, Anders F Björklund <afb algonet.se>  
wrote:


 It seems that D with this storage classes and const-transporting  
 methods  will be almost different D, may be D 2.0 :)


 Or perhaps it should be called D++ ?


No, at first there must be 'D with macros' (like 'C with classes') and  
only then -- D++ :))

-- 
Regards,
Yauheni Akhotnikau
Mar 16 2007
next sibling parent reply Dan <murpsoft hotmail.com> writes:
 No, at first there must be 'D with macros' (like 'C with classes') and  
 only then -- D++ :))


*shudder*

D already has templates.  it shouldn't have a separate macro language.  Having
one indicates that the language itself somehow fails.  Templates *should* be
sufficient.

Using the ++ notation for the language is dangerous.  It allows you to only
upgrade once.  You can't have a D, D++, D 2.0 etc, it just doesn't fit,
'causing the language to completely stagnate.  Then someone else has to come
along and invent a language E.

I think if we properly use 'const' to define something as 'not moving', and
'final' to define something as being 'unchangeable' then you can declare final
const x and be done with it.

The simpler the language is, the better.

Sincerely,
Dan
Mar 16 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Dan wrote:

 I think if we properly use 'const' to define something as 'not
 moving', and 'final' to define something as being 'unchangeable' then
 you can declare final const x and be done with it.
 
 The simpler the language is, the better.


Simplistic does not mean simpler. Your system would be unable to express 
the simplest realities:

void print(const char[] message); // not modifying message

void main()
{
   char[] myMessage = readln();
   print(myMessage); // error! myMessage is changeable!
}

I truly think we've distilled the simplest language within our requirements.

Andrei
Mar 16 2007
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 16 Mar 2007 11:02:39 -0700, Andrei Alexandrescu (See Website For
Email) wrote:



 void print(const char[] message); // not modifying message
 
 void main()
 {
    char[] myMessage = readln();
    print(myMessage); // error! myMessage is changeable!
 }
 
 I truly think we've distilled the simplest language within our requirements.


Maybe the concepts but I'm not so sure about the usage.

Given a function signature that has an array argument, there are two
independant things we might want to remain unchangeable - the reference and
the data referred to. 

To me, the signature ...

  void print(const char[] message)

looks like 'const' is qualifying 'char[]' because that's what it is next
to, and the 'message' looks like it is not qualified. So the signature
looks like it is saying, the data is 'const' but the reference is not.

Thus this below signature looks more like what you are trying to express
...

  void print(char[] const message)

And to make both unchangeable then this looks better to me ...

  void print(const char[] const message)

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Fri, 16 Mar 2007 11:02:39 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 
 

 void print(const char[] message); // not modifying message

 void main()
 {
    char[] myMessage = readln();
    print(myMessage); // error! myMessage is changeable!
 }

 I truly think we've distilled the simplest language within our requirements.


 
 Maybe the concepts but I'm not so sure about the usage.
 
 Given a function signature that has an array argument, there are two
 independant things we might want to remain unchangeable - the reference and
 the data referred to. 
 
 To me, the signature ...
 
   void print(const char[] message)
 
 looks like 'const' is qualifying 'char[]' because that's what it is next
 to, and the 'message' looks like it is not qualified. So the signature
 looks like it is saying, the data is 'const' but the reference is not.


Exactly. All I'm saying is that if you go through the steps of your 
system, you will see that it's unable to implement the notion of modular 
mutability.


 Thus this below signature looks more like what you are trying to express
 ...
 
   void print(char[] const message)
 
 And to make both unchangeable then this looks better to me ...
 
   void print(const char[] const message)


We decided to use final to express symbol non-rebinding.

Andrei
Mar 16 2007
prev sibling parent eao197 <eao197 intervale.ru> writes:
On Fri, 16 Mar 2007 17:56:57 +0300, Dan <murpsoft hotmail.com> wrote:


 No, at first there must be 'D with macros' (like 'C with classes') and
 only then -- D++ :))


 *shudder*


It was a joke.


 D already has templates.  it shouldn't have a separate macro language.   
 Having one indicates that the language itself somehow fails.  Templates  
 *should* be sufficient.


My expirience in C++ and Ruby says that a language must have no macro  
system at all (like in Ruby) or must have a very powerful one (much more  
powerful than in C/C++, Nemerle is a fresh example). If D have started  
movement to support macros it must go as far as possible. I think.


 Using the ++ notation for the language is dangerous.  It allows you to  
 only upgrade once.  You can't have a D, D++, D 2.0 etc, it just doesn't  
 fit, 'causing the language to completely stagnate.  Then someone else  
 has to come along and invent a language E.


E programming language already exists: http://www.erights.org/ ;)
And it grows from the other side of BCPL-C-C++ family -- from Java's  
branch. So the name of D can't be changed to E, only to D++ or D 2.0 :)


 The simpler the language is, the better.


Oberon was a very simple language, but where is it now?
C++ have never been simple. Java isn't a simple language now. Ruby isn't  
simple. And this language are very successful in real world. And D will  
be, I hope.

-- 
Regards,
Yauheni Akhotnikau
Mar 16 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
eao197 wrote:

 No, at first there must be 'D with macros' (like 'C with classes') and 
 only then -- D++ :))


D will get macros - but they won't be text processing macros, they'll be 
abstract syntax tree (AST) processing macros.

C++ programmers often try to use text macros to do syntax tree 
manipulation, but the result usually looks like one tried to use a belt 
buckle to drive screws.
Mar 16 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Sat, 17 Mar 2007 01:41:54 +0300, Walter Bright  
<newshound digitalmars.com> wrote:


 eao197 wrote:

 No, at first there must be 'D with macros' (like 'C with classes') and  
 only then -- D++ :))


 D will get macros - but they won't be text processing macros, they'll be  
 abstract syntax tree (AST) processing macros.


It is very interesting to hear that. Could you say more about the future  
macro system in D? Or it is a secret now?


 C++ programmers often try to use text macros to do syntax tree  
 manipulation, but the result usually looks like one tried to use a belt  
 buckle to drive screws.


Yes, I know. I have used C++ macros a lot in some cases.

-- 
Regards,
Yauheni Akhotnikau
Mar 17 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
eao197 wrote:

 On Sat, 17 Mar 2007 01:41:54 +0300, Walter Bright 
 <newshound digitalmars.com> wrote:
 

 eao197 wrote:

 No, at first there must be 'D with macros' (like 'C with classes') 
 and only then -- D++ :))


 D will get macros - but they won't be text processing macros, they'll 
 be abstract syntax tree (AST) processing macros.


 
 It is very interesting to hear that. Could you say more about the future 
 macro system in D? Or it is a secret now?


It's pretty simple:

	macro foo(args)
	{
		...syntax that gets inserted...
	}

and the args and syntax is evaluated in the context of the invocation of 
the macro, not the definition of the macro. You'll be able to do things 
like:

	macro print(arg)
	{
		writefln(__FILE__, __LINE__, arg);
	}

which get the file and line in the right context. There's no way to do 
that right now.
Mar 17 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Funny, this is beginning to read like dialogue from Sam & Max: Episode 1...

Daniel Keep wrote:

 Walter Bright wrote:

 eao197 wrote:

 On Sat, 17 Mar 2007 01:41:54 +0300, Walter Bright
 <newshound digitalmars.com> wrote:

 D will get macros - but they won't be text processing macros, they'll
 be abstract syntax tree (AST) processing macros.








Bosco: And I might have another item of interest behind the counter...


 It is very interesting to hear that. Could you say more about the
 future macro system in D? Or it is a secret now?






Sam: I accept your thinly veiled invitation to ask about the item behind
the counter.


 It's pretty simple:
 
     macro foo(args)
     {
         ...syntax that gets inserted...
     }




Bosco: Oh, it's a little something I like to call a Tear Gas Grenade
Launcher.


 Oh, VERY slick.


Max: "Tear Gas Grenade Launcher?"  Oh, I *really* want that!


 and the args and syntax is evaluated in the context of the invocation of
 the macro, not the definition of the macro. You'll be able to do things
 like:
 
     macro print(arg)
     {
         writefln(__FILE__, __LINE__, arg);
     }
 
 which get the file and line in the right context. There's no way to do
 that right now.




Bosco: It'll clear out a room full of militant college students in no
time; guaranteed!


 Wow.  <3


Max: I feel really close to you right now.

:P

Question: in terms of usage, will these macros be like functions?  Or
will we able to define, say, a new kind of control structure with
keywords?  Or perhaps even a construct with a trailing curly brace block?

You spoil us Walter, you really do.

	-- 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/
Mar 17 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Daniel Keep wrote:

 Question: in terms of usage, will these macros be like functions?


Yes. No !( ) syntax.


 Or
 will we able to define, say, a new kind of control structure with
 keywords?


No. Abner Hale thwacks such things with "abomination!"


  Or perhaps even a construct with a trailing curly brace block?


Yes.


 You spoil us Walter, you really do.


macros should be the final piece needed to make DSL's work nicely, and 
they are actually rather simple conceptually and implementation-wise. I 
tried for a long time to figure out how to make templates do the work, 
until I finally realized that AST macros are *fundamentally different* 
from templates.

A nice side benefit to macros is we should be able to deprecate lazy.
Mar 17 2007
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 macros should be the final piece needed to make DSL's work nicely, and 
 they are actually rather simple conceptually and implementation-wise. I 
 tried for a long time to figure out how to make templates do the work, 
 until I finally realized that AST macros are *fundamentally different* 
 from templates.


Yup.  It sounds like the implementation will really be quite like the 
new mixin feature wrapped in some syntactic sugar.  Oddly, I'm actually 
looking forward to this.  There have been a few instances where I 
actually needed macros... some being cases where I wanted to define a 
local template function (which is illegal), and others for more bizarre 
uses.


 A nice side benefit to macros is we should be able to deprecate lazy.


I actually like 'lazy' for a narrow range of uses.  It makes creating an 
optimal debug logger exceedingly simple, for example.  Compared to all 
the evil tricks Matthew needed for Pantheios, 'lazy' has a clear and 
measurable benefit.  But if the same thing could be accomplished using 
macros then so much the better.


Sean
Mar 17 2007
prev sibling next sibling parent reply Marcin Kuszczak <aarti interia.pl> writes:
Walter Bright wrote:


 It's pretty simple:
 
 macro foo(args)
 {
 ...syntax that gets inserted...
 }
 
 and the args and syntax is evaluated in the context of the invocation of
 the macro, not the definition of the macro. You'll be able to do things
 like:
 
 macro print(arg)
 {
 writefln(__FILE__, __LINE__, arg);
 }
 
 which get the file and line in the right context. There's no way to do
 that right now.


And what about mixin templates? Couldn't they just be fixed to do this work? 

From docs:
" Unlike a template instantiation, a template mixin's body is evaluated
within the scope where the mixin appears, not where the template
declaration is defined. It is analogous to cutting and pasting the body of
the template into the location of the mixin. It is useful for injecting
parameterized 'boilerplate' code, as well as for creating templated nested
functions, which is not possible with template instantiations. "

For me it looks exactly like this what you want to do with macro. 

What would be a difference?

For me it seems that the whole mixin thing is rather buggy and unusfull at
the moment - for reference see:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/3412.html#N3416


-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Mar 17 2007
parent Walter Bright <newshound digitalmars.com> writes:
See new thread for reply.
Mar 17 2007
prev sibling next sibling parent janderson <askme me.com> writes:
Walter Bright wrote:

 eao197 wrote:

 On Sat, 17 Mar 2007 01:41:54 +0300, Walter Bright 
 <newshound digitalmars.com> wrote:


 eao197 wrote:

 No, at first there must be 'D with macros' (like 'C with classes') 
 and only then -- D++ :))


 D will get macros - but they won't be text processing macros, they'll 
 be abstract syntax tree (AST) processing macros.


 It is very interesting to hear that. Could you say more about the 
 future macro system in D? Or it is a secret now?


 
 It's pretty simple:
 
     macro foo(args)
     {
         ...syntax that gets inserted...
     }
 
 and the args and syntax is evaluated in the context of the invocation of 
 the macro, not the definition of the macro. You'll be able to do things 
 like:
 
     macro print(arg)
     {
         writefln(__FILE__, __LINE__, arg);
     }
 
 which get the file and line in the right context. There's no way to do 
 that right now.


On naming why not use mixin, since they are so similar?

mixin print(arg)
{

}

Then make them typesafe (using alias to get out of type-safty)?


What if you want the file in some other context?  It would be nice to 
have a complete solution to that, which allows some sort of stack 
traversal.  Although I'm not sure its possible, due to not wanting to 
keep this sort of information around at release time.

ie:

      macro print(arg)
      {
          writefln(__FILE__[stack_level], __LINE__[stack_level], arg);
      }

Or even better:

Stack[0].Line; //Current line
Stack[1].Line; //Line one level up
Stack[0].File;
Stack[0].Module;
Stack[0].Function;
Stack[0].NumbArgs; //Some form of reflection
Stack[0].Arg[N];   //Access to the value of the argument (ie Turple of 
values)
Stack[0].ArgIdentifier[N] //String name of the identifier
Stack[0].FuncType	 //The type of function we are in (is it a macro, a 
compile time function a member, a regular function)
ect...

      macro print(arg)
      {
	with(Stack[0])
	{
         	writefln(File, Line, arg);
	}
      }

I guess that would have problems for larger depths.  Perhaps it could be 
limited to two levels (current and parent) or only work for ones that 
can be evaluated at compile time (you would get a compile time error if 
the line number couldn't be evaluated.)  There could be a debug version 
that would work at run time.

-Joel
Mar 17 2007
prev sibling parent eao197 <eao197 intervale.ru> writes:
On Sat, 17 Mar 2007 11:49:59 +0300, Walter Bright  
<newshound digitalmars.com> wrote:


 It's pretty simple:

 	macro foo(args)
 	{
 		...syntax that gets inserted...
 	}

 and the args and syntax is evaluated in the context of the invocation of  
 the macro, not the definition of the macro. You'll be able to do things  
 like:

 	macro print(arg)
 	{
 		writefln(__FILE__, __LINE__, arg);
 	}

 which get the file and line in the right context. There's no way to do  
 that right now.


As I can see the content of macro body will be inserted into AST in the  
place of invocation. But there is not much differences with existing  
C/C++ macro handling (insertion of right __FILE__, __LINE__ is good thing  
anyway).

Is there allowed any access to previous parsed entity? For example, can I  
define macro:

macro some_class_extender(class_name) {
   ...modification of 'class_name' class structure...
}

class MyCoolClass { ... }
some_class_extender( MyCoolClass );

and get the modified version of MyCoolClass after some_class_externder  
invocation?

-- 
Regards,
Yauheni Akhotnikau
Mar 17 2007
prev sibling next sibling parent reply Reiner Pope <no spam.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 

 
 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


So, would this allow you to express the associative array requirement, that the
key must never be changed after it is set?

char[] myKey = "foo";
myAA[myKey] = "bar";
myKey = "something else"; // ERROR: this stuffs up the AA

would you write the getter's signature as superconst?

T set(super const K key) {...}

Is super const allowed as a parameter type?
Mar 16 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Reiner Pope 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);

 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 


 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


 
 So, would this allow you to express the associative array requirement, that
the key must never be changed after it is set?
 
 char[] myKey = "foo";
 myAA[myKey] = "bar";
 myKey = "something else"; // ERROR: this stuffs up the AA
 
 would you write the getter's signature as superconst?
 
 T set(super const K key) {...}
 
 Is super const allowed as a parameter type?


Yes.

Andrei
Mar 16 2007
prev sibling parent Dave <Dave_member pathlink.com> writes:
Andrei Alexandrescu (See Website For Email) Wrote:

 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.
 


'invariant' seems to be the consensus (instead of super const or const!)? If
so, I'd agree that's the best of the three.


 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 



I haven't noticed 'ref' come-up on subsequent posts, but I would strongly favor
this change as well.

- Dave
Mar 23 2007
prev sibling next sibling parent reply Dan <murpsoft hotmail.com> writes:
Bill Baxter Wrote:


 is *already* unreadable (plus I don't think that [3,17] part is legal 
 D).  If any reasonable programmer really did have a need for such a type 


Actually, Bill, it's part of the language spec.
http://digitalmars.com/d/arrays.html
Look up "Rectangular Arrays"
Mar 16 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Dan wrote:

 Bill Baxter Wrote:
 

 is *already* unreadable (plus I don't think that [3,17] part is legal 
 D).  If any reasonable programmer really did have a need for such a type 


 
 Actually, Bill, it's part of the language spec.
 http://digitalmars.com/d/arrays.html
 Look up "Rectangular Arrays"


The only thing even close to that is this:
---
In other languages, this would be called a multidimensional array and be 
declared as:

double matrix[3,3];
---
Note those first three words...
Mar 16 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Dan wrote:

 Bill Baxter Wrote:
 

 is *already* unreadable (plus I don't think that [3,17] part is legal 
 D).  If any reasonable programmer really did have a need for such a type 


 
 Actually, Bill, it's part of the language spec.
 http://digitalmars.com/d/arrays.html
 Look up "Rectangular Arrays"


Read that part of the spec closely, Dan.

--bb
Mar 16 2007
prev sibling next sibling parent reply Reiner Pope <no spam.com> writes:
Andrei Alexandrescu (See Website For Email) Wrote:


 
 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.
 


Is there anything in your discussion about compile-time constants (the sort
that you need for 'static if', etc) ? You spoke a while ago about improving
compile-time evaluation syntax so that there would be no difference at the call
 site between runtime and compile-time evaluation (like for regexps).

It seems like you could get this quite easily by adding just one more parameter
modifier (is this a storage class? I'm not sure) to denote, "any time this
function is called, this parameter must be known at compile-time". Effectively,
it would just be a conversion from this:

RegExpMatch match(static const char[] pattern, char[] text) {...}
...
main()
{
     match("gr[ae]y", din.read());
}

to this:

RegExpMatch match(char[] pattern)(char[] text) {...}
...
main()
{
     match!("gr[ae]y")(din.read());
}

Any plans this way?

Cheers,

Reiner
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:
 

 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.


 Is there anything in your discussion about compile-time constants (the sort
that you need for 'static if', etc) ? You spoke a while ago about improving
compile-time evaluation syntax so that there would be no difference at the call
 site between runtime and compile-time evaluation (like for regexps).


I understand this is high on Walter's list. The syntax discussed is:

// dispatched when the pattern is known at compile time
RegExpMatch match(const char[] p)(const char[] p, char[] text) {...}
// dispatched when the pattern is a runtime string
RegExpMatch match()(const char[] p, char[] text) {...}


 It seems like you could get this quite easily by adding just one more
parameter modifier (is this a storage class? I'm not sure) to denote, "any time
this function is called, this parameter must be known at compile-time".
Effectively, it would just be a conversion from this:
 
 RegExpMatch match(static const char[] pattern, char[] text) {...}
 ...
 main()
 {
      match("gr[ae]y", din.read());
 }
 
 to this:
 
 RegExpMatch match(char[] pattern)(char[] text) {...}
 ...
 main()
 {
      match!("gr[ae]y")(din.read());
 }
 
 Any plans this way?


The above forces only compile-time constant regexps. What we need is to 
dispatch depending on compile-time constant vs. run-time string.

Combined with macros, this will essentially allow a call to writefln to 
morph, depending on its arguments, into putch(), fputs(), write(), 
fprintf() - or execute today's dynamically-checked writefln.


Andrei
Mar 16 2007
next sibling parent reply Reiner Pope <reiner none.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:


 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.


 Is there anything in your discussion about compile-time constants (the 
 sort that you need for 'static if', etc) ? You spoke a while ago about 
 improving compile-time evaluation syntax so that there would be no 
 difference at the call  site between runtime and compile-time 
 evaluation (like for regexps).


 
 I understand this is high on Walter's list.


Good to hear that.

  The syntax discussed is:

 
 // dispatched when the pattern is known at compile time
 RegExpMatch match(const char[] p)(const char[] p, char[] text) {...}
 // dispatched when the pattern is a runtime string
 RegExpMatch match()(const char[] p, char[] text) {...}


That seems fine, but I can't help wondering, "why the double-declaration 
of p in the first instance?" and also, "why does the second instance of 
match even need to be a template?".


 

 It seems like you could get this quite easily by adding just one more 
 parameter modifier (is this a storage class? I'm not sure) to denote, 
 "any time this function is called, this parameter must be known at 
 compile-time". Effectively, it would just be a conversion from this:

 RegExpMatch match(static const char[] pattern, char[] text) {...}
 ...
 main()
 {
      match("gr[ae]y", din.read());
 }

 to this:

 RegExpMatch match(char[] pattern)(char[] text) {...}
 ...
 main()
 {
      match!("gr[ae]y")(din.read());
 }

 Any plans this way?


 
 The above forces only compile-time constant regexps. What we need is to 
 dispatch depending on compile-time constant vs. run-time string.


Well, I kind of took it for granted that the above suggestion would 
allow for overloading by compile-time-constness (with a preference to 
the compile-time version when there's a choice). So that you could write:

RegExpMatch match(static const char[] pattern, char[] text){...}
RegExpMatch match(char[] pattern, char[] text) {...}


 
 Combined with macros, this will essentially allow a call to writefln to 
 morph, depending on its arguments, into putch(), fputs(), write(), 
 fprintf() - or execute today's dynamically-checked writefln.


True. I was also interested in another use of this, though: allowing a 
library-time implementation of tuples (since what kind of feature is one 
that can't be implemented in the library?). There are basically two 
reasons that this can't be done at the moment:

alias Tuple!(int, double) myTuple;
myTuple[0] = 5; // First reason
foreach (val; myTuple) // Second reason
{
     writef(val);
}

I would imagine that you could implement the first feature as:

struct MyTupleImpl(TypeList...)
{
    ...
    TypeList[i] opIndex(static const int i) {...}
// We grab the return type based on the parameter, so we must know it at 
compile time. It makes no sense to have a runtime version of this.
}

and at a stretch, you could imagine the second feature as working in a 
similar way: your compile-time representation of the foreach delegate is 
either a char[] to be mixed in, or an expression alias, when we get that:

struct MyTupleImpl(TypeList...)
{
     int opApply(static const char[] code)
     {
         // iterate through tuple; this iteration would actually have to 
be generated with CTFE, but you get the idea
         {
             TypeList[i] __special_foreach_key = whatever;
             mixin(code);
         }
     }
}

Cheers,

Reiner
Mar 16 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:


 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.


 Is there anything in your discussion about compile-time constants 
 (the sort that you need for 'static if', etc) ? You spoke a while ago 
 about improving compile-time evaluation syntax so that there would be 
 no difference at the call  site between runtime and compile-time 
 evaluation (like for regexps).


 I understand this is high on Walter's list.


 Good to hear that.
 
  The syntax discussed is:

 // dispatched when the pattern is known at compile time
 RegExpMatch match(const char[] p)(const char[] p, char[] text) {...}
 // dispatched when the pattern is a runtime string
 RegExpMatch match()(const char[] p, char[] text) {...}


 That seems fine, but I can't help wondering, "why the double-declaration 
 of p in the first instance?" and also, "why does the second instance of 
 match even need to be a template?".


Good question. It must be a template by the pigeonhole principle: each 
compile-time regex generates in theory different code, so you must have 
as many distinct functions as strings.


 It seems like you could get this quite easily by adding just one more 
 parameter modifier (is this a storage class? I'm not sure) to denote, 
 "any time this function is called, this parameter must be known at 
 compile-time". Effectively, it would just be a conversion from this:

 RegExpMatch match(static const char[] pattern, char[] text) {...}
 ...
 main()
 {
      match("gr[ae]y", din.read());
 }

 to this:

 RegExpMatch match(char[] pattern)(char[] text) {...}
 ...
 main()
 {
      match!("gr[ae]y")(din.read());
 }

 Any plans this way?


 The above forces only compile-time constant regexps. What we need is 
 to dispatch depending on compile-time constant vs. run-time string.


 Well, I kind of took it for granted that the above suggestion would 
 allow for overloading by compile-time-constness (with a preference to 
 the compile-time version when there's a choice). So that you could write:
 
 RegExpMatch match(static const char[] pattern, char[] text){...}
 RegExpMatch match(char[] pattern, char[] text) {...}
 

 Combined with macros, this will essentially allow a call to writefln 
 to morph, depending on its arguments, into putch(), fputs(), write(), 
 fprintf() - or execute today's dynamically-checked writefln.


 
 True. I was also interested in another use of this, though: allowing a 
 library-time implementation of tuples (since what kind of feature is one 
 that can't be implemented in the library?). There are basically two 
 reasons that this can't be done at the moment:
 
 alias Tuple!(int, double) myTuple;
 myTuple[0] = 5; // First reason
 foreach (val; myTuple) // Second reason
 {
     writef(val);
 }
 
 I would imagine that you could implement the first feature as:
 
 struct MyTupleImpl(TypeList...)
 {
    ...
    TypeList[i] opIndex(static const int i) {...}
 // We grab the return type based on the parameter, so we must know it at 
 compile time. It makes no sense to have a runtime version of this.
 }
 
 and at a stretch, you could imagine the second feature as working in a 
 similar way: your compile-time representation of the foreach delegate is 
 either a char[] to be mixed in, or an expression alias, when we get that:
 
 struct MyTupleImpl(TypeList...)
 {
     int opApply(static const char[] code)
     {
         // iterate through tuple; this iteration would actually have to 
 be generated with CTFE, but you get the idea
         {
             TypeList[i] __special_foreach_key = whatever;
             mixin(code);
         }
     }
 }


That's not on the list yet. One thing at a time :o).


Andrei
Mar 17 2007
parent Reiner Pope <reiner none.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) Wrote:


 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.


 Is there anything in your discussion about compile-time constants 
 (the sort that you need for 'static if', etc) ? You spoke a while 
 ago about improving compile-time evaluation syntax so that there 
 would be no difference at the call  site between runtime and 
 compile-time evaluation (like for regexps).


 I understand this is high on Walter's list.


 Good to hear that.

  The syntax discussed is:

 // dispatched when the pattern is known at compile time
 RegExpMatch match(const char[] p)(const char[] p, char[] text) {...}
 // dispatched when the pattern is a runtime string
 RegExpMatch match()(const char[] p, char[] text) {...}


 That seems fine, but I can't help wondering, "why the 
 double-declaration of p in the first instance?" and also, "why does 
 the second instance of match even need to be a template?".


 
 Good question. It must be a template by the pigeonhole principle: each 
 compile-time regex generates in theory different code, so you must have 
 as many distinct functions as strings.
 


But how about the runtime implementation of match()? There's no code 
generation there...



 
 That's not on the list yet. One thing at a time :o).


Sure thing. It's just that we've already got so much more after D 1.0 
that I can't help wanting more :o).

Cheers,

Reiner
Mar 17 2007
prev sibling parent Reiner Pope <reiner none.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Combined with macros, this will essentially allow a call to writefln to 
 morph, depending on its arguments, into putch(), fputs(), write(), 
 fprintf() - or execute today's dynamically-checked writefln.


So is there going to be a way to specify at the function (or template) 
definition site that the function (or template) produces a compile-time 
string which is to be mixed into the call site. eg:

// The 'mixin' specifies that the result should be mixed into the call site.
mixin char[] writefln(/*params*/)
{
     ... // Generate code
     return generatedCode;
}


Sounds good.


Reiner
Mar 17 2007
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruno Medeiros wrote:

 What is the status of the experimental designs ...



I asked this because yesterday, out of nowhere, I started thinking about 
this problem, and as a kind of a mental exercise I came to a working 
design. It seems kinda pointless, since you already made your design, 
but I'll show this one nevertheless. Consider it a late entry to the max 
challenge :P . Still, there are some aspects presented here, that I 
don't how they would work on your planned design (like those keyed by 
the questions).
Most of the terms here are tentative, and so is the syntax. Please 
consider the syntax separately from the semantics and conceptualization. 
Errors may be present in the text. This design is presented as is, 
without any warranty of any kind. :P

CONCEPTUALIZATION

There are 3 major kinds of D entities:

Values (expressions), types, and templates. (and labels too I guess...)

Values are characterized by properties that define what one can do with 
the value. The most important of these properties is the type. D offers 
a very rich mechanism to query and manipulate types (typeof(..), is(..) 
expression, auto, type parameters, etc.), much better than any other 
statically typed language I know. But the type is not the only 
"property" of an expression. There are others, such as whether an 
expression is an lvalue or not, if it can be assigned, etc.. The problem 
so far is that D does not offer a good mechanism to query and manipulate 
such "type properties".

Let's consider the following type properties:

R: is the value readable.
C: is the value readable at compile time (compile time constant).
&: is the value referenciable.
W: is the value writable. (explained later)

I can't find a good term for these "extended type properties" or 
"extended value properties" so I'll just call it QUX for now. Silly, I 
know, but whatever. And I will call "core type" to the current notion of 
type, which is what typeof(..) returns.

So, with these QUX, what are the valid combinations of them?
They are:

R
CR
R&
RW&
W&

(I'm skipping the explanation of why, since I think that's clear, see 
examples below). Furthermore, these property combinations are related in 
the following hierarchy of conversion:

   R
  /  \
CR  R&   W&
      \  /
       RW&

Examples of the QUX for various values in current D:

42	// CR - A literal is a constant.
var	// RW& - As in:  int var;
fvar	// R& - As in:  const fvar; fvar = 2; It's like 'final'
func()	// R - the value of a function is readonly and not referenciable
	// W - No example in current D for W

Let's give some tentative keywords for the possible QUX combinations:

CR  - const
RW& - ref
W&  - wronly ref
R&  - rdonly ref
R   - rdonly

Now, recall the following: QUX describe the properties of a value. The 
first thing you may think now is that one can use QUX to declare 
variables of the same QUX type. That's not entirely accurate. For 
example you can't declare a variable of QUX R, because a var is always 
either referenciable, or a (compile-time) constant. There are no R 
variables.
Specifying a var as rdonly will create a R&. Specifying no QUX will 
create a RW&. Specifying ref in a var declaration will alse create a RW& 
var, but the identity will be the same as the var in the given 
initializer. ref will preserve the "reference" (memory location) of the 
initializer. This is mentioned to clear the declaration semantics.
Examples:

int varA = varX; 	// var is RW&
const int varB = 1;	// var is CR
rdonly int varC = 2;	// var is R&
rdonly ref int varD = &varX; // var is RW& too
wronly ref int varE = &varX; // var is W&

varA will be a copy of varX, while varD will be the same as varX (same 
identity). After definition, varA and varD will have the same QUX.

And what about the definitions of function parameters, and function 
return types?
There are some minor differences. In function return types, if no QUX is 
specified, then the QUX is rdonly (as it is currently in D). In function 
parameters, if no QUX is specified the QUX is rdonly too (this is 
different from current D, but is considered a nice improvement. Function 
arguments are almost never modified anyway).

What about composing types? That is, when one has a composite type 
(array, pointers, etc.), how does one specify QUX for each of the type 
components?

Well for this var:
   int[]* var;
then QUX are specified like this:

rdonly int[]* var; // var (the pointer) is rdonly
(rdonly int[])* var; // the pointer target (the array) is rdonly
(rdonly int)[]* var; // the members of the array are rdonly
rdonly (rdonly (rdonly int)[])* var; // All are rdonly

Note that some QUX don't make sense in certain declarations, like 
declaring an array member as ref, like this:
   (ref int)[] var;
because the members of arrays are refs already. This could be an error 
or simply ignored.

What about auto?
auto does not in any way capture the QUX, just the core type (as in 
typeof(..) ).
   rdonly var;
   auto foo = var;  // foo is not rdonly

How do we templatize and parameterize QUX?
Let's see by example, looking at previous design challenges:

The id function:

T id(expr T) (T a) {
   return a;
}

So, "expr T" denotes that T is not a normal type parameter, but an 
"extended type parameter". Besides the core type, it will also hold 
information about the QUX. id can be instanced manually or with IFTI.


manipulation, but let's first recall what max does.
Consider these vars:

a = 3;
b = 9;
const fvar;  // fvar is 'final'
fvar = 1;

And now some examples of max usage:

max(1, 2)	2 of QUX CR
max(a, 2)	a of QUX R
max(a, b)	b of QUX RW&
max(a, func())	a of QUX R
max(a, fvar)	a of QUX R&


As requested, max preservers the greatest common QUX information.
Here's how we define max:


maxExtType!(A,B) max(expr A :: rdonly, expr B :: rdonly) (A a, B b) {
   if(a >= b)
     return a;
   else
     return b;
}


Of note: The 'T :: U' syntax means specialize the template if T can be 
converted to U. This is a variant of the current 'T : U' syntax which 
means specialize if T is the *same* as U. In both these constructs, U 
can be a QUX, but only if T is an "extended type parameter" (a parameter 
declared with expr).

maxExtType is the key to complete the challenge. It defines the maximum 
common extended type of A and B. This is defined as:


template maxExtType(expr A, expr B) {
   static if( !is(typeof(A) == typeof(B)) ) {
     alias maxCoreType(A, B) maxType; // Type cannot be ref
   } else {
     static if( is(A == ref) && is(B == ref))
       alias (ref typeof(A)) maxType;
     else static if( is(A :: rdonly ref) && is(B :: rdonly ref))
       alias (rdonly ref typeof(A)) maxType;
     else static if( is(A :: wronly ref) && is(B :: wronly ref) )
       alias (wronly typeof(A)) maxType;
     else static if( is(A :: rdonly) && is(B :: rdonly) )
       alias (rdonly typeof(A)) maxType;
     else
       static assert(false, "No common extended type for:"+A+" and "+B);
   }
}


So, like mentioned in the original challenge thread, if the core type of 
A and B are not the same, then maxExtType cannot be a ref. That's what 
the first static if checks for (note: an exception can be made for 
object types). The subsequent static ifs check for increasingly less 
restrictive common QUXs. It's possible that a common QUX does not exist 
if one is R& and the other is W& for example.


What about lazy?
In this design, lazy simply isn't considered as a QUX, as it simply is 
not a property of an expression. There are no lazy expressions. After a 
lazy FOO variable is created (which must be initialized), the variable 
becomes for *all effects* indistinguishable from a FOO delegate() , that 
is, a delegate returning type FOO. Thus, lazy can't also be 
parameterized/templatized.


IMMUTABILITY

Immutability, as in, "transitive immutability" is achieved as a type 
modifier with the keyword "immut". An immut value means that any other 
member obtained from the original value cannot be modified, and so on. 
The members of immut values are rdonly and immut. immut is not a QUX, it 
is a type modifier that modifies (and is part of) the core type. This 
means that immut appears in "typeof(..)", and consequentely is also 
captured by auto. This is the only sensible behavior, since immut 
describes a property of the referenced data of that expression, and must 
be preserved upon assignments (and thus part of the core type). This is 
unlike QUX, since QUX only describe properties of the immediate-value of 
an expression, which is copied in assignments. I.e., you can assign a 
rdonly value to a non-rdonly var, but you can't assign an immut value to 
a non-immut (normal) var. This shows how immut and QUX are somewhat 
different in nature. Also immut vars and not automatically rdonly, they 
are rdonly only if 'rdonly' is also specified.
An example:

   immut Foo[] fooar;
then:
   typeof(fooar[0]) == rdonly immut Foo;


TODO
*Syntax to specify the "this" of a method as immut. Maybe do it like C++?
*A way to conveniently specify/templatize methods that are identical and 
only vary in the mutability of it's types (like 'romaybe' in Javari).


The following describes a particular use case for rdonly and wronly:

VARIANT COMPOSITE TYPES.

Consider this hierarchy:

FooBar extends Foo extends Object
Xpto extends Object

Suppose we have an array of Foo:
   Foo[] fooarr;

The classic contravariance problem is, is fooarr safely castable to 
Object[] ? On first sight one might think yes, since Foo is an Object, 
then Foo[] is an Object[]. But that is not the case since an Object[] 
array is an array that one can put an Xpto object into:
   (cast(Object[]) fooarr)[0] = new Xpto();
which would break type safety, since we would have a Xpto in an array of 
Foo's. What happens is that we have some array operations (like readers) 
that remain safe , but others do not (like writers).
Java allows that cast, but has runtime checks on array member 
assignments, and throws an exception if the type safety is violated like 
in the example above.
Can a language provide (compile time) support for safe casting? With 
rdonly and wronly it can.
   We have that Foo[] cannot be cast to Object[], but it can be safely 
cast to (rdonly Object)[]. And then:

   fooarr2 = cast((rdonly Object)[]) fooarr;
   fooarr2[0] = new Xpto(); // Not allowed
   fooarr2[0].doSomething(); // Allowed

Assignments won't be allowed, but reading is allowed. Conversely, the 
array type parameter can be contravariantly cast, from Foo[] to (wronly 
Foobar)[].

   // Ok because fooarr[] is of type wronly FooBar
   fooarr[0] = new FooBar();
   // Not allowed because you can't read fooarr[0];
   fooarr[0].doSomething();

This was the main motivation I saw for the use of wronly, however, this 
mechanism is quite simple (as in, simplistic) and limited. It's not as 
powerful as Java's generics, which allow a greater degree of 
functionality with lower-bounded types. As such, it may not be worth 
having wronly just because of this. Still, I guess wronly could also be 
used in place of 'out' parameters.


SYNTAX AND TERMS SUBJECT TO CHANGE:

QUX - EVT (Extended Value Properties) or ETP (Extended Type Properties) 
? Or 'attributes' instead of 'properties' ? But definitely not "storage 
class", that term sucks. :o
immut  - perhaps 'immutable'?
rdonly - perhaps 'readonly' or 'final'?
wronly - perhaps 'writeonly'?
expr
"::" - Ideally, it would be better that the ":" of template 
specialization would behave the same as the ":" of the is(..) expression.



Comments are welcome.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 17 2007
prev sibling next sibling parent 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 

 
 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
prev sibling parent reply Tyler Knott <tywebmail mailcity.com> writes:
I think I've got this.  Is the following right?

*final variables can be assigned only once in their lifetime, but are otherwise
normal variables (i.e. they *do* have a 
memory address), except where constant folded by the compiler (this should be
completely transparent to the programmer).

*const and invariant only make sense when applied to references, otherwise they
are ignored or (preferably) errors.

*const references cannot be used to mutate the data they reference, but the
data they reference may be mutated directly 
or through other non-const, non-invariant references.

*invariant references only reference data that will never be mutated (e.g.
final variables).

*Both const and invariant references can be reassigned unless they are also
final references.

*Conversely, when final is applied to the declaration of a reference, only that
reference is protected from mutation, 
not the data it references, unless that reference is also const or invariant.

*Neither const nor invariant references can be cast to non-const or
non-invariant references directly.

*The address of any variable or the value of any reference (of compatible type)
can be assigned to const references.

*Only the addresses of final variables (I'm sure of this), the direct result of
"new" statements (not sure on this one), 
and the values of other invariant references may be assigned to invariant
references.

*const and invariant are viral (i.e. all references in the data referenced by a
const or invariant reference is also 
const or invariant, respectively, when access through the const or invariant
reference).

*final, when applied directly to POD structures (structs and array references),
means no members of that structure can 
be modified after assignment, but is non-viral to references within the POD
structure. (Not sure on this.)

*Function declarations cannot overloaded based on const or invariant. (Pretty
sure on this.)
---------------------
Here are a whole bunch of contrived examples of most of these rules:

final int w = 5; 	//legal
final int x = 55;	//ditto
int y = 6; 		//legal
int z;			//ditto
const int i;		//either (preferably) illegal or ignored
invariant int i;	//ditto

x = 6; 			//illegal
y = 7; 			//legal

int* mut_pointer;
mut_pointer = &x; 	//illegal: this would allow x to be mutated
mut_pointer = &y; 	//obviously legal
*mut_pointer = 10;	//obviously legal

const int* const_pointer;
const_pointer = &x;		//legal
const_pointer = &y; 		//Also legal: const_pointer is mutable (non-final)
z = *const_pointer;		//Legal: you can read through const references
*const_pointer = 10;		//illegal: you can't mutate through const references

invariant int* inv_pointer = &x; 	//Legal: x is final and never changes
inv_pointer = &y 			//Illegal: y is non-final may change
inv_pointer = &w;			//Legal: inv_pointer is mutable (non-final)
y = *inv_pointer;			//Legal: data can be read through inv_pointer
*inv_pointer = y;			//Illegal: you can't mutate through invariant references

final int* final_pointer = &y;		//obviously legal
z = *final_pointer;			//obviously legal
*final_pointer = 2; 			//legal: y can be changed through final_pointer
final_pointer = &z; 			//illegal: final_pointer already assigned

final int* final_pointer2 = &x;		//illegal: final_pointer2 allows mutation

final const int* final_const_pointer = &x; //Legal: const pointer does not
allow mutation
final_const_pointer = &w;		//Illegal: final_const_pointer is final and cannot
be mutated
y = *final_const_pointer;		//Obviously legal
*final_const_pointer = y;		//Obviously illegal

final const int* final_const_pointer2 = &y; //Legal: neither y nor const care
about underlying mutability

final invariant int* final_inv_pointer = &x; //Legal
final invariant int* final_inv_pointer2 = &y; //Illegal: y is mutable

struct S
{
	int a;
	char[] b;
	static S* opCall()
	{
		S* ret = new S;
		s.b = "test";
		return ret;
	}
}

final S final_s;	//final_s exists on the stack or in the global scope

final_s.a = 6;		//Illegal: s is final
final_s.b = "hello"; 	//ditto

final S final_s2 = *S();	//Legal
final_s2.b[2] = 'd';		//Legal: final is non-viral

final S* s_pointer = new S;	//Legal, *(s_pointer) exists on the heap
s_pointer.a = 6;		//Legal, *(s_pointer) can be mutated through s_pointer
s_pionter.b = "hello"; 		//ditto
s_pointer = new S;		//Illegal: s_pointer is already assigned

final S* s_pointer2 = S();	//Obviously legal

const S* const_s_pointer = new S;	//Legal
y = const_s_pointer.a;			//Legal
const_s_pointer.a = 5;			//Illegal
const_s_pointer = S();			//Legal: const_s_pionter can be reassigned

invariant S* inv_s_pointer = new S;	//Legal
y = inv_s_pionter.a;			//Legal
inv_s_pointer.a = 5;			//Illegal
inv_s_pointer = S();			//Not sure, but probably illegal: S* points to mutable
data,
					//even though there are no other references to it.  How do
					//invariant pointers work with the static opCall() workaround for
					//missing struct constructors? Does NRVO deal with this?

class C
{
	int a;
	final S* s_in_c;
	this() { s_in_c = new S; } 	//Is it legal to assign final values in
constructors?
					//What about in a static opCall() for structs?
	void increment_a() { this.a++; }
}

final C final_c = new C();
final_c = new C();		//Illegal: final_c already assigned.
y = final_c.a;			//Legal
final_c.a = x;			//Also legal
final_c.increment_a();		//Ditto

const C const_c = new C();
const_c = new C();		//Legal: reference const_c can be reassigned
const_c.a = y;			//Illegal: cannot mutate through const reference
const_c.increment_a();		//Legal??? Is the object's "this" reference non-const?

invariant C inv_c = new C();
inv_c = new C();		//legal: reference inv_c can be reassigned
ivn_c.a = y;			//Illegal: cannot mutate through invariant reference
inv_c.increment_a();		//Illegal???  The object shouldn't be able to be modified
at all, but
				//how could the compiler catch this?
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Tyler Knott wrote:

 I think I've got this.  Is the following right?
 
 *final variables can be assigned only once in their lifetime, but are 
 otherwise normal variables (i.e. they *do* have a memory address), 
 except where constant folded by the compiler (this should be completely 
 transparent to the programmer).


Correct.


 *const and invariant only make sense when applied to references, 
 otherwise they are ignored or (preferably) errors.


Correct.


 *const references cannot be used to mutate the data they reference, but 
 the data they reference may be mutated directly or through other 
 non-const, non-invariant references.


Correct.


 *invariant references only reference data that will never be mutated 
 (e.g. final variables).


Ambiguously expressed. But I think I see what you mean, e.g. you can 
take the address of a final int and bind it to an invariant int*, like so:

final int x = 42;
immutable int* p = &x; // correct


 *Both const and invariant references can be reassigned unless they are 
 also final references.


Correct.


 *Conversely, when final is applied to the declaration of a reference, 
 only that reference is protected from mutation, not the data it 
 references, unless that reference is also const or invariant.


Correct.


 *Neither const nor invariant references can be cast to non-const or 
 non-invariant references directly.


Correct.


 *The address of any variable or the value of any reference (of 
 compatible type) can be assigned to const references.


Correct. (Just like in C++.)


 *Only the addresses of final variables (I'm sure of this), the direct 
 result of "new" statements (not sure on this one), and the values of 
 other invariant references may be assigned to invariant references.


Yes, yes (and more), and yes.

New statements can be solved easily by just requiring people to qualify 
the type created:

invariant int* p = new invariant int(42);

User-defined types will have a chance to define constructors for 
invariant objects. Those constructors will have the chance of modifying 
the object being constructed, but won't be able to alias 'this' and 
member addresses to modifiable pointers.

The deeper problem is with functions that return pointers that could be 
assigned to either mutable or invariant symbols. For example, array.dup. 
Take a look:

int[] array = [1, 2, 3];
invariant int[] brray = array.dup; // should work
invariant int[] crray = array.dup; // should work, too!

I am working on a solution for this issue. The problem is rather 
general. Consider a function char[] readln() that reads a line from the 
standard input, creating a fresh string each call. That string should be 
assigned to char[] or invariant char[].


 *const and invariant are viral (i.e. all references in the data 
 referenced by a const or invariant reference is also const or invariant, 
 respectively, when access through the const or invariant reference).


"Transitive." Yes.


 *final, when applied directly to POD structures (structs and array 
 references), means no members of that structure can be modified after 
 assignment, but is non-viral to references within the POD structure. 
 (Not sure on this.)


Correct. "final x" freezes all of x's bits.


 *Function declarations cannot overloaded based on const or invariant. 
 (Pretty sure on this.)


Walter is mildly unconvinced about such overloads' utility, I think they 
should be allowed without being required.

I'll snip your examples, which are correct and also raise a couple of 
interesting questions that are being worked on.


Andrei
Mar 19 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 19 Mar 2007 22:34:13 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Tyler Knott wrote:

 *const and invariant only make sense when applied to references, 
 otherwise they are ignored or (preferably) errors.


 
 Correct.


Can 'const' and 'invariant' apply to structs, especially ones that contain
references.

  struct Foo
  {
      char[] s;
      char c;
  }

  const Foo f;  // Is this a mistake then?
  f.s[0] = 'a'; // okay???
  f.s = "xyz";  // okay???
  f.s = "def".dup; // okay ???
  f.s.length = 1;  // okay?
  f.s ~= 'a'; // okay??
  f.c = 'a';   // okay???
  
  const Foo somefunc();
  f = somefunc; // okay??

  Foo someotherfunc();
  f = someotherfunc; // okay??

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
20/03/2007 4:45:27 PM
Mar 19 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 19 Mar 2007 22:34:13 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:
 

 Tyler Knott wrote:

 *const and invariant only make sense when applied to references, 
 otherwise they are ignored or (preferably) errors.


 Correct.


 
 Can 'const' and 'invariant' apply to structs, especially ones that contain
 references.
 
   struct Foo
   {
       char[] s;
       char c;
   }
 
   const Foo f;  // Is this a mistake then?


That code is fine. I should have said "const and invariant make sense 
only when applied to types that are, or contain, references". Sorry.


   f.s[0] = 'a'; // okay???


No.


   f.s = "xyz";  // okay???


Yes.


   f.s = "def".dup; // okay ???


Yes.


   f.s.length = 1;  // okay?


Yes.


   f.s ~= 'a'; // okay??


Yes.


   f.c = 'a';   // okay???


Yes.


   const Foo somefunc();
   f = somefunc; // okay??


Yes.


   Foo someotherfunc();
   f = someotherfunc; // okay??


Yes. Non-const transforms into const no problem.


Andrei
Mar 19 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Mon, 19 Mar 2007 22:34:13 -0700, Andrei Alexandrescu (See Website For
 Email) wrote:


 Tyler Knott wrote:

 *const and invariant only make sense when applied to references, 
 otherwise they are ignored or (preferably) errors.


 Correct.


 Can 'const' and 'invariant' apply to structs, especially ones that 
 contain
 references.

   struct Foo
   {
       char[] s;
       char c;
   }

   const Foo f;  // Is this a mistake then?


 
 That code is fine. I should have said "const and invariant make sense 
 only when applied to types that are, or contain, references". Sorry.
 

   f.s[0] = 'a'; // okay???


 
 No.
 

   f.s = "xyz";  // okay???


 
 Yes.
 

   f.s = "def".dup; // okay ???


 
 Yes.
 

   f.s.length = 1;  // okay?


 
 Yes.
 

   f.s ~= 'a'; // okay??


 
 Yes.
 

   f.c = 'a';   // okay???


 
 Yes.
 

   const Foo somefunc();
   f = somefunc; // okay??


 
 Yes.
 

   Foo someotherfunc();
   f = someotherfunc; // okay??


 
 Yes. Non-const transforms into const no problem.
 
 
 Andrei


What?? If f is 'const', how are any of those "f.s =" assignments allowed?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 20 2007
parent reply Tyler Knott <tywebmail mailcity.com> writes:
Bruno Medeiros wrote:

 
 What?? If f is 'const', how are any of those "f.s =" assignments allowed?
 


Because f is a POD (Plain Old Data) structure and not a reference you can
modify the data in the structure, but because 
it's declared const you can't modify any data referenced.  If you want f.s to
be unassignable then declare f to be final 
Foo, though you can then modify the data referenced by f.s so f.s[0] = 'a';
becomes legal.

For example:

struct Foo
{
     char[] s = "hello";
     char c;
}

const Foo const_foo;
final Foo final_foo;
final const Foo const_final_foo;
const Foo* const_foo_pointer = new Foo;

const_foo.s = "test"; //Legal: data directly modified (const only invalidates
modification through references)
final_foo.s = "test"; //Illegal: cannot modify data in final variables
const_final_foo.s = "test"; //Illegal: cannot modify data in final variables
const_foo_pointer.s = "test"; //Illegal: cannot modify data through const
references

const_foo.s[0] = 'a'; //Illegal: cannot modify data through const references
		      //(const declaration is transitive to const_foo.s reference)
final_foo.s[0] = 'a'; //Legal: you're not modifying any data in final_foo, only
data referenced by it
const_final_foo.s[0] = 'a'; //Illegal: cannot modify data through const
references
const_foo_pointer.s[0] = 'a'; //Illegal: cannot modify data through const
references
Mar 20 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Tyler Knott wrote:

 Bruno Medeiros wrote:

 What?? If f is 'const', how are any of those "f.s =" assignments allowed?


 
 Because f is a POD (Plain Old Data) structure and not a reference you 
 can modify the data in the structure, but because it's declared const 
 you can't modify any data referenced.  If you want f.s to be 
 unassignable then declare f to be final Foo, though you can then modify 
 the data referenced by f.s so f.s[0] = 'a'; becomes legal.
 
 For example:
 
 struct Foo
 {
     char[] s = "hello";
     char c;
 }
 


Duh, of course. I misread and was thinking Foo was a class and not a struct.



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