www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Const Ideas

reply "Craig Black" <cblack ara.com> writes:
The 2.008 release is an improvement, but it seems like there is still a lot 
of dissatisfaction with the current const stuff.  Janice proposed an idea 
for constifying instance member functions using const(this).  I like that 
idea.  It is explicit and can be used as a prefix without ambiguity.  If we 
did this, I would suggest getting rid of the postfix syntax.

const(this):
void func1() { ... }
void func2() { ... }
void func3() { ... }

or

const(this) void func1() { ... }
const(this) void func2() { ... }
const(this) void func3() { ... }

This is both explicit and remedies the ambiguity between the instance 
pointer and the return type being const.

Another point that Janice makes is that it is confusing that const(X) isn't 
the same as const X.  To solve this problem, I propose using const(ref) to 
constify references.  This removes ambiguity and makes things explicit.

const X x;  // The data is const, the reference is mutable
const(ref) X x;  // The data is mutable, the reference is const
const(ref) const X x;  // Everything is const, nothing is mutable

-Craig 
Nov 30 2007
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 11/30/07, Craig Black <cblack ara.com> wrote:
 Janice proposed an idea
 for constifying instance member functions using const(this).

That actually wasn't me. I like the idea (a lot), but I can't claim credit for inventing it. I did come up with the idea of extending it to const(identifier) though.
 If we did this, I would suggest getting rid of the postfix syntax.

I would certainly agree with that!
 const X x;  // The data is const, the reference is mutable

The problem I have with this is that I believe X should mean the same as (X). So if you accept that, const X x; must mean the same thing as const(X) x; And if you believe that const(...) has to mean "everything inside the brackets is const" (which is what I believe) then you have to conclude that const X x must mean "x is completely and absolutely const, and nothing about it is mutable". That's actually what it means right now (so long as you omit the brackets). That's why I argue that you need something else - something /outside the brackets/ - to mean "let the reference be mutable". (And obviously, that mechanism should only be available for reference types).
Nov 30 2007
next sibling parent "Craig Black" <cblack ara.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.201.1196446640.2338.digitalmars-d puremagic.com...
 On 11/30/07, Craig Black <cblack ara.com> wrote:
 Janice proposed an idea
 for constifying instance member functions using const(this).

That actually wasn't me. I like the idea (a lot), but I can't claim credit for inventing it. I did come up with the idea of extending it to const(identifier) though.
 If we did this, I would suggest getting rid of the postfix syntax.

I would certainly agree with that!
 const X x;  // The data is const, the reference is mutable

The problem I have with this is that I believe X should mean the same as (X). So if you accept that, const X x; must mean the same thing as const(X) x; And if you believe that const(...) has to mean "everything inside the brackets is const" (which is what I believe) then you have to conclude that const X x must mean "x is completely and absolutely const, and nothing about it is mutable". That's actually what it means right now (so long as you omit the brackets). That's why I argue that you need something else - something /outside the brackets/ - to mean "let the reference be mutable". (And obviously, that mechanism should only be available for reference types).

I see the dilemma. So the probem with using const(ref) is that there would be no way to say that the data is const but the reference is mutable. This is also a limitation of the current implementation is it not?
Nov 30 2007
prev sibling parent "Craig Black" <cblack ara.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.201.1196446640.2338.digitalmars-d puremagic.com...
 On 11/30/07, Craig Black <cblack ara.com> wrote:
 Janice proposed an idea
 for constifying instance member functions using const(this).

That actually wasn't me. I like the idea (a lot), but I can't claim credit for inventing it. I did come up with the idea of extending it to const(identifier) though.
 If we did this, I would suggest getting rid of the postfix syntax.

I would certainly agree with that!
 const X x;  // The data is const, the reference is mutable

The problem I have with this is that I believe X should mean the same as (X). So if you accept that, const X x; must mean the same thing as const(X) x; And if you believe that const(...) has to mean "everything inside the brackets is const" (which is what I believe) then you have to conclude that const X x must mean "x is completely and absolutely const, and nothing about it is mutable". That's actually what it means right now (so long as you omit the brackets). That's why I argue that you need something else - something /outside the brackets/ - to mean "let the reference be mutable". (And obviously, that mechanism should only be available for reference types).

We could also add mutable(ref), but I don't think mutable is even a keyword.
Nov 30 2007
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I think the new const system makes sense. I think of variables as being
compile time pointers to memory (basically).

Furthermore, const() is like a compile time function that takes a type T and
returns type T that is now a constant.

const (no parenthesis) is telling the compiler something.

Similarly, import; tells the compiler to import a symbol table from a file,
whereas import("file") is a compile time function that reads in a file
and returns its data (just like std.read() but at compile time).

Henceforth, let CTF = 'compile time function'.


Thus:

int a;
Adds an entry to the compiler's variable table named 'a' that references
memory that is an int.

const(int) a;
Add an entry named 'a' that references memory that is a constant int. The
const() CTF takes the type int and returns a new type that is a constant int.

const int a;
Add a *constant* entry named 'a' that references memory that is a mutable
int.

const const(int) a;
Adds a constant entry named 'a' that references a constant integer.

Let's deconstruct that conceptually:
variable declaration := [mutability] type name;
Mutability is if the compiler's name entry can be changed (rebinded). It is
optional, and defaults to being mutable.

Type is the type of memory the variable references.

And name is of course the name.

In the above:
const is the mutability of the compiler's variable table entry.
const(int) is a CTF that returns a type - it is the actual type.
a is obviously the name.


Let's consider const(int) a; again.

a = 10; // the compiler sees this as rewriting its internal table:
// something like this: variableMap['a'] = &10;
// Of course, the address of an immediate is pretty silly, but it is consistent
// with thinking about, say, string literals.
// Let's just say the storage for a literal integer is optimized away later
// so the real program just sees immediates.

++a; // also rewriting the table:
// variableMap['a'] = &(variableMap['a'] + 1);

Once again, with strings, that makes more sense:

const(char[]) str = "hello";
// variableMap['str'] = &"hello";

str = replace(str, "hello", "world");
// variableMap['str'] = &what_replace_returns

The actual literal "hello" string pointed to is not changed, it is just
discarded, and may be left behind for the gc to collect later.


From a usability standpoint, I think the last case there of reusing variables
for string replaces is why I think I like the current system best:

string a = "hello";
a = replace(a, ...);

Just works, making me pretend I have in place replaces.

With the proposed const(char[]) making everything const, this would break.




-- 
Adam D. Ruppe
http://arsdnet.net
Nov 30 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Craig Black wrote:
 const(ref) const X x;  // Everything is const, nothing is mutable

One too many consts. I will not stand for any solution taht has "const" more than once in the declaration.
Nov 30 2007
next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fipn3b$j8n$2 digitalmars.com...
 Craig Black wrote:
 const(ref) const X x;  // Everything is const, nothing is mutable

One too many consts. I will not stand for any solution taht has "const" more than once in the declaration.

Right. I wasn't thinking straight when I proposed this as Janice pointed out. Simply const X x; will do the trick.
Nov 30 2007
parent reply "Craig Black" <cblack ara.com> writes:
"Craig Black" <cblack ara.com> wrote in message 
news:fipnds$ktf$1 digitalmars.com...
 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:fipn3b$j8n$2 digitalmars.com...
 Craig Black wrote:
 const(ref) const X x;  // Everything is const, nothing is mutable

One too many consts. I will not stand for any solution taht has "const" more than once in the declaration.

Right. I wasn't thinking straight when I proposed this as Janice pointed out. Simply const X x; will do the trick.

I still like const(ref) though, but it doesn't solve the problem of allowing mutable references to const data. That would would still require something like const(X) x; Which brings us back to where we are already. Another idea is, mutable(ref) const X x; Which is convoluted. Also I don't think that mutable is a keyword anyway.
Nov 30 2007
next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.206.1196453000.2338.digitalmars-d puremagic.com...
 Well, I'm still gunning for

    const (X)& x;

 for mutable refs to const classes. Since I come from a C++ background,
 & means "reference of" to me, and this reads straightforwardly as "x
 is a reference to const X".

 Of course, x would be a reference even /without/ the ampersand - such
 is the nature of classes in D. But writing it explicitly allows one to
 put it outside the brackets

I now better understand why you proposed this syntax. I guess it's not so bad. I can't think of anything better.
Nov 30 2007
parent reply Jason House <jason.james.house gmail.com> writes:
Craig Black wrote:

 
 "Janice Caron" <caron800 googlemail.com> wrote in message
 news:mailman.206.1196453000.2338.digitalmars-d puremagic.com...
 Well, I'm still gunning for

    const (X)& x;

 for mutable refs to const classes. Since I come from a C++ background,
 & means "reference of" to me, and this reads straightforwardly as "x
 is a reference to const X".

 Of course, x would be a reference even /without/ the ampersand - such
 is the nature of classes in D. But writing it explicitly allows one to
 put it outside the brackets

I now better understand why you proposed this syntax. I guess it's not so bad. I can't think of anything better.

Technically, I proposed the syntax. Janice didn't like it at first but has now come full circle. I've had some second thoughts about stuff, but I'm still able to convince myself that a novel syntax for rebindable constant objects is best. Here's what I consider to be requirements: const(...) must mean that everything within the parens is constant "const X" and "const(X)" must mean the same thing Rebindable constant objects are important to have const(X) foo(){...} should mean that what it returns is constant. "non-rebindable const(X) x = foo();" should be allowed "rebindable const(X) x = foo();" should be allowed "const(X) foo(){non-rebindable const(X) x; return x;}" should be allowed "const(X) foo(){rebindable const(X) x; return x;}" should be allowed. From those requirements, "const(X) x;" must mean that x can not be rebound. Using "const(X)& x;" for a rebindable definition seems to be the best I can come up with. Do people disagree with any of the requirements I listed? Most are just sanity requirements, but may not have general agreement. Beyond that, is there a better for for a rebindable definition?
Nov 30 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 On 11/30/07, Jason House <jason.james.house gmail.com> wrote:
 Craig Black wrote:
 Technically, I proposed the syntax.  Janice didn't like it at first but has
 now come full circle.

That's right. I think my earlier attempt was something like "const(X)ref" or "ref const(X)". I came full circle and now fully support Craig's idea, largely because I think there may come a time in the future when D has C++-style references. If and when that day comes, "&" will be preferable to "ref" for the same reason that "*" is preferable to "ptr".

Pointers can be stacked like T***. References cannot. The 'ref' can only ever apply to the head. So I think a syntax with ref in front would be workable if Walter wants to go that way. In some ways it makes more sense to put the sigil for references out in front because, for the most part, ref doesn't affect the way you use the thing. ref T acts just like a T for most purposes, whereas T* is a quite different thing. --bb
Dec 01 2007
prev sibling next sibling parent "Craig Black" <craigblack2 cox.net> writes:
  "const X" and "const(X)" must mean the same thing

Sorry if this is a stupid question, but if const XY means that both X and Y are const, then const(X)Y will not be equivalent to const XY and thus const(X) will not always be equivalent to const X So what does everyone mean when they make this a requirement? It seems to be a contradiction with the current approach to const.
Dec 02 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:
 const(X) must mean the same thing as const X, for all X. Unless you
 have that, there will always be complaints.

Let's look at it another way. Consider a class C: alias const(C) CC; void foo(CC c, CC f) { auto d = c; d = f; } This kind of code can be expected, and it should work. It should also work if CC is: alias const(int) CC; because this can happen with metaprogramming. The insight is that, although a type can be const, it can always be copied (shallow copy) without affecting the const. If a variable is bound to a const type, being able to rebind it doesn't affect the const'ness, because it's just another copy. In other words, const'ness of types, const-correctness, etc., *only matters* for a type with references in it. You cannot undermine const-correctness by rebinding a variable that is typed as const. Next, a storage class says something about how the variable is stored, not its type. We'd like to be able to say a variable is stored in read-only memory (even if that is only conceptual). Hence, we'd like to give it a storage class 'const' to put it in read-only memory. Pulling on that string, in order to have transitive const, using a const storage class must also make the type of the variable const, too. Thus, we have: const(T) x; which types x as having a const type, which matters only for references, and: const T x; which types x as having a const type, *and* (conceptually) puts x in read-only memory after it is initialized. I suggest writing some actual code using const. I think you'll find it is rather natural in practice. For example, nobody is going to write: const(int) x = 3; when they want a compile-time constant, they'll write: const int x = 3; The only time you'll see the form: const(T) x; is when T is a reference type, or is an unknown type that could be a reference type. And the only reason one would write this is to protect the references, not x itself. The natural question then, is why have: const(int) x; at all? The reason is when one is deconstructing types using templates, and then reconstructing them, the const-correctness of what is being referred to must be carried along, else the const-correctness is lost.
Dec 02 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Janice Caron wrote:
 const(X) must mean the same thing as const X, for all X. Unless you
 have that, there will always be complaints.

...[explanation snipped] The natural question then, is why have: const(int) x; at all? The reason is when one is deconstructing types using templates, and then reconstructing them, the const-correctness of what is being referred to must be carried along, else the const-correctness is lost.

Great explanation. Any ETA on an updated const article? I think this one is out of date since it still talks about final. http://www.digitalmars.com/d/const.html --bb
Dec 03 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Any ETA on an updated const article?
 I think this one is out of date since it still talks about final.
 http://www.digitalmars.com/d/const.html

Yes, I need to fix that.
Dec 03 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 Well, I'm still gunning for
 
     const (X)& x;
 
 for mutable refs to const classes. Since I come from a C++ background,
 & means "reference of" to me, and this reads straightforwardly as "x
 is a reference to const X".
 
 Of course, x would be a reference even /without/ the ampersand - such
 is the nature of classes in D. But writing it explicitly allows one to
 put it outside the brackets.

I like where this is going, but my guess is that when/if Walter ever introduces reference types, the syntax for reference-to-T will be "ref T" like the parameter signature rather than C++'s "T&". So if you're going peel off the hidden ref, I think you might should make it: ref X x --> const ref(T) x; or --> const (T)ref x; or --> ref const(T) x; #3 seems pretty good to me. But anyway no one knows what Walter will decide to do. About references generally, one big difference between C++ references and D classes is that you can't reassign a C++ reference. // C++ int& x = y; x = z; /// error In that sense, the C++ references themselves are always 'const' (aka head-const / final). I seem to remember some example in Stroustrup that explained why this behavior was important. But anyway, D's class references aren't like that, and it makes me wonder if more general D reference types in D would be like that. --bb
Nov 30 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:
 Janice Caron wrote:
 Well, I'm still gunning for

     const (X)& x;

 for mutable refs to const classes. Since I come from a C++ background,
 & means "reference of" to me, and this reads straightforwardly as "x
 is a reference to const X".

 Of course, x would be a reference even /without/ the ampersand - such
 is the nature of classes in D. But writing it explicitly allows one to
 put it outside the brackets.

I like where this is going, but my guess is that when/if Walter ever introduces reference types, the syntax for reference-to-T will be "ref T" like the parameter signature rather than C++'s "T&". So if you're going peel off the hidden ref, I think you might should make it: ref X x --> const ref(T) x; or --> const (T)ref x; or --> ref const(T) x; #3 seems pretty good to me. But anyway no one knows what Walter will decide to do. About references generally, one big difference between C++ references and D classes is that you can't reassign a C++ reference. // C++ int& x = y; x = z; /// error

Er. Not 'error' per se, it just doesn't rebind x, it modifies y.
 In that sense, the C++ references themselves are always 'const' (aka 
 head-const / final).
 I seem to remember some example in Stroustrup that explained why this 
 behavior was important.  

I remembered. You can't reassign them because it's ambiguous whether you want to make x just refer to the new thing or call the opAssign on the previously bound thing. Ok, so D classes get around this by eliminating opAssign for classes and saying you can *only* rebind the reference. But I don't think that will fly for references to structs or built-in value types. --bb
Nov 30 2007
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
 So if you're going peel off the hidden ref, I think you might should make 
 it:

     ref X x --> const ref(T) x;
 or          --> const (T)ref x;
 or          --> ref const(T) x;

 #3 seems pretty good to me.  But anyway no one knows what Walter will 
 decide to do.

Good point here. Here's another idea. If we reverse the meaning of const(X) then we could do this: const X x; // all const const(X) x; // data const, ref mutable X const x; // data mutable, ref const
Nov 30 2007
next sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Fri, 30 Nov 2007 15:27:20 -0600, Craig Black wrote:

 
 Here's another idea.  If we reverse the meaning of const(X) then we could do 
 this:
 
 const X x;  // all const
 const(X) x; // data const, ref mutable
 X const x; // data mutable, ref const

I like this, nice and clear. ++vote.
Nov 30 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Craig Black wrote:
 Here's another idea.  If we reverse the meaning of const(X) then we could do 
 this:
 
 const X x;  // all const
 const(X) x; // data const, ref mutable

This is what we have now.
 X const x; // data mutable, ref const 

This breaks transitivity of const.
Dec 02 2007
parent Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Craig Black wrote:
 Here's another idea.  If we reverse the meaning of const(X) then we 
 could do this:

 const X x;  // all const
 const(X) x; // data const, ref mutable

This is what we have now.
 X const x; // data mutable, ref const 

This breaks transitivity of const.

That's our goal. Other languages have the final keyword for this; we don't want to feel left out.
Dec 03 2007
prev sibling parent BC <NOTmi_emayl_adrez hotmail.com.remove.not> writes:
On Fri, 30 Nov 2007 20:44:33 -0000, Bill Baxter  =

<dnewsgroup billbaxter.com> wrote:

 Janice Caron wrote:
 Well, I'm still gunning for
      const (X)& x;
  for mutable refs to const classes. Since I come from a C++ backgroun=


 & means "reference of" to me, and this reads straightforwardly as "x
 is a reference to const X".
  Of course, x would be a reference even /without/ the ampersand - suc=


 is the nature of classes in D. But writing it explicitly allows one t=


 put it outside the brackets.

I like where this is going, but my guess is that when/if Walter ever =

 introduces reference types, the syntax for reference-to-T will be "ref=

 T" like the parameter signature rather than C++'s  "T&".

 So if you're going peel off the hidden ref, I think you might should  =

 make it:

      ref X x --> const ref(T) x;
 or          --> const (T)ref x;
 or          --> ref const(T) x;

 #3 seems pretty good to me.  But anyway no one knows what Walter will =

 decide to do.

#2 is most similar to const(T)[] x and const(T)* x etc.
 About references generally, one big difference between C++ references =

 and D classes is that you can't reassign a C++ reference.
       // C++
       int& x =3D y;
       x =3D z;  /// error

 In that sense, the C++ references themselves are always 'const' (aka  =

 head-const / final).
 I seem to remember some example in Stroustrup that explained why this =

 behavior was important.  But anyway, D's class references aren't like =

 that, and it makes me wonder if more general D reference types in D  =

 would be like that.

 --bb

imo c++ should have had &r =3D &x to rebind r to x. maybe d could do 'ref r =3D x' or 'ref r =3D ref x'
Dec 02 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
Well, I'm still gunning for

    const (X)& x;

for mutable refs to const classes. Since I come from a C++ background,
& means "reference of" to me, and this reads straightforwardly as "x
is a reference to const X".

Of course, x would be a reference even /without/ the ampersand - such
is the nature of classes in D. But writing it explicitly allows one to
put it outside the brackets.
Nov 30 2007
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Fri, 30 Nov 2007 15:27:20 -0600, Craig Black wrote:

 So if you're going peel off the hidden ref, I think you might should
 make it:

     ref X x --> const ref(T) x;
 or          --> const (T)ref x;
 or          --> ref const(T) x;

 #3 seems pretty good to me.  But anyway no one knows what Walter will
 decide to do.

Good point here. Here's another idea. If we reverse the meaning of const(X) then we could do this: const X x; // all const const(X) x; // data const, ref mutable X const x; // data mutable, ref const

On that note, we could try to keep Janice's idea that const X = const(X) and Adam's explanation of compile time function. const X x; // data const X const x; // ref const const(X x); // both const This would mean that const(T) takes a type T and returns a constant of it. Since in the last one, const(X x) takes a class and ref it will return a const of both. Equivalents of the above to help demonstrate the concept. const(X) x; // data const X const(x); // ref const const(X) const(x); // both const
Nov 30 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/30/07, Denton Cockburn <diboss hotmail.com> wrote:
 const X x;  // all const
 const(X) x; // data const, ref mutable

I like this, nice and clear.

I don't think I'll ever like any scheme in which const(X) != const X.
Nov 30 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/30/07, Jason House <jason.james.house gmail.com> wrote:
 Craig Black wrote:
 Technically, I proposed the syntax.  Janice didn't like it at first but has
 now come full circle.

That's right. I think my earlier attempt was something like "const(X)ref" or "ref const(X)". I came full circle and now fully support Craig's idea, largely because I think there may come a time in the future when D has C++-style references. If and when that day comes, "&" will be preferable to "ref" for the same reason that "*" is preferable to "ptr". If it's /only/ classes we're talking about, it's no big deal either way, but if referencing gets more ubiquitious in the future, less typing => better. So Craig gets the kudos for invention on this one. Nice one, Craig!
Nov 30 2007
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sat, 01 Dec 2007 06:35:46 +0000, Janice Caron wrote:

 On 11/30/07, Jason House <jason.james.house gmail.com> wrote:
 Craig Black wrote:
 Technically, I proposed the syntax.  Janice didn't like it at first but
 has now come full circle.

That's right. I think my earlier attempt was something like "const(X)ref" or "ref const(X)". I came full circle and now fully support Craig's idea, largely because I think there may come a time in the future when D has C++-style references. If and when that day comes, "&" will be preferable to "ref" for the same reason that "*" is preferable to "ptr". If it's /only/ classes we're talking about, it's no big deal either way, but if referencing gets more ubiquitious in the future, less typing => better. So Craig gets the kudos for invention on this one. Nice one, Craig!

Based off of what you said in my other post, Walter will not change D's transitivity, Craig's proposal violates this. As a lot of the discussion here has suggested a solution for having a const ref with mutable data. So if I am correct then the real problem becomes with, const(char)* foo == const(char*) foo const(char)* foo != const char* foo and thus const X x != const(X) x That is to say that const() means the reference can be rebound and const does not. In this case I will re-propose Adam's idea to explain it that const() returns a constant of what is inside. const TYPE * foo // *foo immutable, foo mutable const(TYPE) * foo // same as above const(TYPE *) foo // foo and *foo immutable, but foo can be rebound const(TYPE * foo) // nothing mutable, no rebinding of foo TYPE * const foo // Same as above It would appear this meets at least most of the complaints const() does not have a special meaning, everything can be achieved with one const keyword, transitivity holds, no ambiguity, everything in const() is const. The only problem is that it would break all previous code, unless you assume const grabs everything after it so that the first and last are the same.
Dec 01 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/1/07, Jesse Phillips <jessekphillips gmail.com> wrote:
 Based off of what you said in my other post, Walter will not change D's
 transitivity, Craig's proposal violates this.

Hmm... Someone's misunderstood something. I totally agree with Walter that transitive const is the right way to go.
 As a lot of the discussion
 here has suggested a solution for having a const ref with mutable data.

I don't think so. It's more about the distinction between const X and const(X). What we're after is a syntax for mutable ref to const data (not the other way round). What I'm saying is, if X is a class, then const X x; // fully const const(X) x; // fully const const(X)& x; // mutable ref to const data There shall be /no/ way to specify const ref to mutable data. Further, if X is not a class (say it's a struct or an int or something), then const(X)& x; // Errror - will not compile.
 So if I am correct then the real problem becomes with,
 const X x != const(X) x

Yes. I've been saying that for a long time now. const(X) must mean the same thing as const X because otherwise it's just silly.
 const TYPE * foo  // *foo immutable, foo mutable
 const(TYPE) * foo // same as above
 const(TYPE *) foo // foo and *foo immutable, but foo can be rebound

I stress again the general principle that const X must mean the same thing as const(X). Thus must be true regardless of the type of X. In particular, it must be true when X == TYPE *, and hence "const TYPE *" needs to mean the exact same thing as "const(TYPE *)". The principles that "everything inside the brackets is const", and "if the brackets are omitted, everything is const", cause no problems /except/ for class references. Pointers are not a problem. Only for class references do we need extra syntax, and it was for this purpose that I proposed "const(X)&". (I wasn't the first person to suggest it though).
 It would appear this meets at least most of the complaints const() does
 not have a special meaning, everything can be achieved with one const
 keyword, transitivity holds, no ambiguity, everything in const() is
 const.

const(X) must mean the same thing as const X, for all X. Unless you have that, there will always be complaints.
 The only problem is that it would break all previous code,

D1 doesn't even /have/ const, so that's hardly true. The D2 branch is experimental, and those of us using it are full expect things to change. It's kind of the whole point of the branch.
Dec 01 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/1/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:
 Pointers can be stacked like T***.  References cannot.

You are completely correct, of course. T&& is the same type as T& (or indeed, T&&&&&&&). Honestly, I don't mind if we end up with a syntax of ref const(X) x; // mutable reference to const data instead of const(X)& x; // mutable reference to const data Either will make me happy.
Dec 01 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/1/07, Janice Caron <caron800 googlemail.com> wrote:
 On 12/1/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:
 Pointers can be stacked like T***.  References cannot.

You are completely correct, of course. T&& is the same type as T& (or indeed, T&&&&&&&). Honestly, I don't mind if we end up with a syntax of ref const(X) x; // mutable reference to const data instead of const(X)& x; // mutable reference to const data Either will make me happy.

Actually, the "ref" way is better than the "&" way. (Do I get to change my mind again?) Here's why. Imagine a time in the future when we have references to things that aren't classes - say, ints, structs, whatever. When that day comes, we'll need a way to distinguish between "assign the reference" and "assign the data". Well, the obvious syntax for that is x = y; // assign the data x ref= y; // assign the reference Obviously, &= is already taken! :-)
Dec 01 2007
prev sibling next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 12/3/07, Craig Black <craigblack2 cox.net> wrote:
 Sorry if this is a stupid question, but if

 const XY

 means that both X and Y are const, then

But it doesn't. I don't understand what you're saying. A statement like "const XY x;" would mean that x is fully const and of type XY. A statement like "const X Y x;" just won't compile.
Dec 02 2007
parent "Craig Black" <cblack ara.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.224.1196658519.2338.digitalmars-d puremagic.com...
 On 12/3/07, Craig Black <craigblack2 cox.net> wrote:
 Sorry if this is a stupid question, but if

 const XY

 means that both X and Y are const, then

But it doesn't. I don't understand what you're saying. A statement like "const XY x;" would mean that x is fully const and of type XY. A statement like "const X Y x;" just won't compile.

I guess using X and Y is bad since you assume they are both types.. Am I wrong in assuming the following? const X* x; is not equivalent to const(X)* x; Thus const X is not always equivalent to const(X)
Dec 03 2007
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On Dec 3, 2007 2:34 PM, Craig Black <cblack ara.com> wrote:
 I guess using X and Y is bad since you assume they are both types..
 Am I wrong in assuming the following?

 const X* x;

 is not equivalent to

 const(X)* x;

 Thus const X is not always equivalent to const(X)

OK. Start again, You've misunderstood me. My X stands for /everything between the word const and the identifier being declared/. (Not literally the symbol "X"). So I would want "const X* x" to be interchangeable with "const(X*) x", since, in this case, /everything between the word const and the identifier being declared/ is "X*".
Dec 03 2007
parent reply "Craig Black" <cblack ara.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.227.1196693680.2338.digitalmars-d puremagic.com...
 On Dec 3, 2007 2:34 PM, Craig Black <cblack ara.com> wrote:
 I guess using X and Y is bad since you assume they are both types..
 Am I wrong in assuming the following?

 const X* x;

 is not equivalent to

 const(X)* x;

 Thus const X is not always equivalent to const(X)

OK. Start again, You've misunderstood me. My X stands for /everything between the word const and the identifier being declared/. (Not literally the symbol "X"). So I would want "const X* x" to be interchangeable with "const(X*) x", since, in this case, /everything between the word const and the identifier being declared/ is "X*".

Right! And the same principle can be applied to references as well. So "const X x;" could be interpreted to be interchangeable with "const (X x);" (even though technically the latter that will not compile). Thus your const X == const(X) rule holds with "const(X) x;" and "const X x;"
Dec 03 2007
parent reply "Craig Black" <cblack ara.com> writes:
"Craig Black" <cblack ara.com> wrote in message 
news:fj16ut$qgf$1 digitalmars.com...
 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.227.1196693680.2338.digitalmars-d puremagic.com...
 On Dec 3, 2007 2:34 PM, Craig Black <cblack ara.com> wrote:
 I guess using X and Y is bad since you assume they are both types..
 Am I wrong in assuming the following?

 const X* x;

 is not equivalent to

 const(X)* x;

 Thus const X is not always equivalent to const(X)

OK. Start again, You've misunderstood me. My X stands for /everything between the word const and the identifier being declared/. (Not literally the symbol "X"). So I would want "const X* x" to be interchangeable with "const(X*) x", since, in this case, /everything between the word const and the identifier being declared/ is "X*".

Right! And the same principle can be applied to references as well. So "const X x;" could be interpreted to be interchangeable with "const (X x);" (even though technically the latter that will not compile). Thus your const X == const(X) rule holds with "const(X) x;" and "const X x;"

Just to expound further, the pointer and reference syntax seems difference since the reference is implicit. Just think of "const X x;" as "const X& x;" and you will see that the same principle that applies to pointers should also apply to references.
Dec 03 2007
parent reply "Craig Black" <cblack ara.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.229.1196702116.2338.digitalmars-d puremagic.com...
 On 12/3/07, Craig Black <cblack ara.com> wrote:
 Just to expound further, the pointer and reference syntax seems 
 difference
 since the reference is implicit.  Just think of  "const X x;" as "const 
 X&
 x;" and you will see that the same principle that applies to pointers 
 should
 also apply to references.

Yes, I think we're on the same page here. Of course, only classes have references. Structs don't, ints don't, etc., but for classes, my preference would be for all four of the following to be exactly equivalent: const C c; const(C) c; const C& c; const(C&) c; (Which leaves open the possibility of "const(C)& c;" to mean mutable ref to const data"). That's not the status quo, however

That syntax would looks OK, but I think it also makes sense to make "const(C) c" equivalent to "const(C)& c;". Walter said that this is how the syntax already works. Am I misunderstanding something? What I don't understand is why Walter and others think that "C const c" violates transitivitiy. What do they mean by transitivity?
Dec 03 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
Craig Black wrote:
 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.229.1196702116.2338.digitalmars-d puremagic.com...
 On 12/3/07, Craig Black <cblack ara.com> wrote:
 Just to expound further, the pointer and reference syntax seems 
 difference
 since the reference is implicit.  Just think of  "const X x;" as "const 
 X&
 x;" and you will see that the same principle that applies to pointers 
 should
 also apply to references.

references. Structs don't, ints don't, etc., but for classes, my preference would be for all four of the following to be exactly equivalent: const C c; const(C) c; const C& c; const(C&) c; (Which leaves open the possibility of "const(C)& c;" to mean mutable ref to const data"). That's not the status quo, however

That syntax would looks OK, but I think it also makes sense to make "const(C) c" equivalent to "const(C)& c;". Walter said that this is how the syntax already works. Am I misunderstanding something?

We don't like the syntax. It makes a tiny bit of sense, with that description, but it's unintuitive and error-prone.
 What I don't understand is why Walter and others think that "C const c" 
 violates transitivitiy.  What do they mean by transitivity?

"C const c" -> c is a pointer that cannot be reassigned, but you can modify its members. This violates transitivity, the property that you cannot follow a series of const pointers/references and end up with something mutable. It is also useful, but it isn't useful as a public interface sort-of-thing; it's useful at a relatively small scope. Which is why Walter hasn't implemented it; he doesn't see enough of a benefit yet.
Dec 03 2007
parent reply "Craig Black" <cblack ara.com> writes:
 "C const c" -> c is a pointer that cannot be reassigned, but you can 
 modify its members.

Right.
 This violates transitivity, the property that you cannot follow a series 
 of const pointers/references and end up with something mutable. It is also 
 useful, but it isn't useful as a public interface sort-of-thing; it's 
 useful at a relatively small scope. Which is why Walter hasn't implemented 
 it; he doesn't see enough of a benefit yet.

If that is correct, then transitivity just seems like an artificial restriction for no reason. It's not like we are violating some fundamental law here. I still don't see a good reason not to allow "C const c" syntax. To me, it's straightforward. However, it may complicate the compiler implementation. I wouldn't know.
Dec 03 2007
parent Christopher Wright <dhasenan gmail.com> writes:
Craig Black wrote:
 If that is correct, then transitivity just seems like an artificial 
 restriction for no reason.  It's not like we are violating some fundamental 
 law here.  I still don't see a good reason  not to allow "C const c" syntax. 
 To me, it's straightforward.  However, it may complicate the compiler 
 implementation.  I wouldn't know. 

You're right in that it's an artificial restriction. As for complicating the implementation, I doubt that. It should be easier to do head-const than transitive const. You have to arrange for an initial assignment, which could be awkward. The main issue is language bloat, I think. This is a common feature of other languages, though, so that in itself is an argument in favor of considering the feature. And the fact that it can help find local bugs is an argument in favor of implementing it. I think people have been expecting const always to give a rebindable reference for reference types, and then wanting final in addition. Maybe. But I'm not sure.
Dec 03 2007
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Adam D. Ruppe, el 30 de noviembre a las 13:38 me escribiste:
 int a;
 Adds an entry to the compiler's variable table named 'a' that references
 memory that is an int.
 
 const(int) a;
 Add an entry named 'a' that references memory that is a constant int. The
 const() CTF takes the type int and returns a new type that is a constant int.
 
 const int a;
 Add a *constant* entry named 'a' that references memory that is a mutable
 int.

But now you lost the idea of transitive constness (if your compile-time pointer is const, the value it points to should be const). This doesn't break your "model" if you think as if D works like Python, where int are inmutables, but you can rebind the variable (your compile-time pointer). Then: const int a = 1; means "I have a variable named 'a' that points to some int that has the value 1 and I can't change where it points to (I can't rebind it)". a = 2; is an error const(int) b = 1; means "I have a variable named 'b' that points to some int, conceptually the same int as 'a', because there is no need to have more than 2 inmutable ints with the same value in the program, but I can change where 'b' points to (I can rebind it).". so b = 2; is ok So graphically: +---+ a -> | 1 | <- b +---+ and after b = 2; +---+ +---+ a -> | 1 | b -> | 2 | +---+ +---+ Of course this is a "conceptual" model, otherwise there would not be value passing and must be a reference internall, which I think is not that efficient ;) This is basically what happens with pointers and the values they point to. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Did you know the originally a Danish guy invented the burglar-alarm unfortunately, it got stolen
Nov 30 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/3/07, Craig Black <cblack ara.com> wrote:
 Just to expound further, the pointer and reference syntax seems difference
 since the reference is implicit.  Just think of  "const X x;" as "const X&
 x;" and you will see that the same principle that applies to pointers should
 also apply to references.

Yes, I think we're on the same page here. Of course, only classes have references. Structs don't, ints don't, etc., but for classes, my preference would be for all four of the following to be exactly equivalent: const C c; const(C) c; const C& c; const(C&) c; (Which leaves open the possibility of "const(C)& c;" to mean mutable ref to const data"). That's not the status quo, however
Dec 03 2007