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

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

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

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

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

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.

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

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

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.

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