any news on const/invariant?

[Janice Caron]

On Nov 28, 2007 11:45 AM, Don Clugston <dac at nospam.com.au> wrote:
> Janice Caron wrote:
> > On 11/27/07, David Gileadi <foo at bar.com> wrote:
> >> While maybe a bit of typing, I really like the const(this) form--its
> >> intent is very clear IMHO.  And
> >>
> >> const(this)
> >> {
> >>      int foo();
> >>      int bar();
> >> }
> >>
> >> isn't too bad either.
> >
> > For what it's worth, I completely agree with this.
> Me too.

A thought occurs to me. (And it's a good one). Since we're considering
making const(this) an attribute, why not extend it to
const(identifier), for any identifier. That is, const(identifier)
would syntactically be considered an attribute, and could go anywhere
version(identifier) could go. It's meaning would be: within the
specified scope, the named identifier shall be consisdered const (and
likewise for invariant). Allowing "this" to be merely a special case
of identifier, does indeed allow us to declare const member functions:

    const(this) void f();

as well as the abovementioned grouping.

    const(this)
    {
         int foo();
         int bar();
    }

but, just look what /else/ you could do with it!

    const(x) /* let x be const within these braces */
    {
        /* x is const here */
    }

or...

    int x = 42;
    const(x): /* x is const from here on */
    x = 100; /* error */

Why, it's almost like having final back! (Only, with crystal clear
syntax and without the confusion). Other advantages include

    const(outer)

allows you to check const correctness via outer instead of via this.
That is, "I promise not to modify any member variables of an outer
class". And so on.

Going back to Walter's point that C++ allows const as a storage class
just fine, I want to really stress that that claim is a red herring.
When you declare a member function as const in C++, you are /not/
using "const the storage class". In fact, in C++, "const the storage
class" is really the same thing as D's invariant type constructor - it
is an assertion that the variable will never be changed, ever. It
certainly doesn't mean "don't modify 'this'". That's why I think it's
important to separate in our minds the distinction between "storage
class" and "attribute". There are places in D where the existing const
syntax is just fine - e.g. Walter's example

    const x = 5;

However, just because we want that to be a legal statement, it does
not follow that we need to give the keyword const (without brackets)
all the syntactic abilities of an attribute. On the other hand,
const(identifier) makes absolutely /perfect/ sense as an attribute.
It's beautiful, and would give us expressive power that even C++
doesn't have, while at the same time allowing everything that Walter
wants to keep with only minor syntactic changes (e.g. "const(this)"
instead of "const" for member functions, const-statements in the
grammar instead of "const" as an attribute).

This is a testing time for const. We're already doing better than C++
in many respects, but the final deal still isn't nailed down yet, so
while there's still time, let's consider this one. There are people
who haven't upgraded to D2 yet - they obviously won't mind the change;
there are those of us who like to "live on the edge" - well, we won't
mind change either, because we understand that's the price for living
on the edge. So the proposal is:

(1) disallow "const" as an attribute
(2) introduce "const statements" so that "const x = 5" still compiles.
(3) allow "const(identifer)" to be an attribute, which makes
identifier const within the scope of the attribute

and likewise for invariant