any news on const/invariant?

[Walter Bright]

Janice Caron wrote:
> I just checked the grammar of C++, and C++'s list of
> storage-class-specifiers doesn't actually include "const", so I think
> neither of us is using the term correctly.

The C++ spec doesn't call const a storage class explicitly, but it is 
clear in saying what the "linkage" of a const declaration is, which is 
what the storage class is. It also fits in the grammar with storage 
classes, i.e. you can do things like:
	const static int x = 3;

> The similar looking, but drastically different statement "const int *

So I infer you agree that C++ is not consistent or intuitive <g>.

> p = whatever;" uses const as a type constructor, equivalent to D's
> const(int). In C++, this can also be written as "int const * p" (a
> style I prefer as it now reads from right to left as "p is a pointer
> to const int").



> As far as member functions go, the C++ const storage class cannot be
> applied to them because it makes no sense (because a member function
> cannot be declared at global scope. By definition, it is always in the
> scope of the enclosing class). Thus, when I write (in C++)
> 
>     class A
>     {
>         int f() const;
>     }
> 
> The word "const" is /not/ acting as a "storage class". Instead, it
> tells us that "this" is const within f.
> 
> 
> 
>> D's const storage class applies to the declaration. That makes intuitive
>> sense, although it is different from C++.
> 
> But what makes no sense is the very notion of a function (as opposed
> to its "this" pointer) being const.
> 
> All functions are, by definition, invariant. That is, the bytes of
> machine code which are executed, may not be changed by any part of the
> program. If you take the address of those bytes of machine code,
> that's a pointer to invariant. The RAM utilitised during that
> function's execution (the stack, or the member variables, or both) are
> part of that function's context, and we care whether or not the
> function is allowed to modify those variables in the course of its
> execution. Thus, the kind of constness we are talking about is the
> constness of the function's context, not of the function itself. You
> can call that a "storage class" if you want, but it means something
> very different from a variable declared at global scope.
> 
> So what you're saying as that the meaning of the word "const" changes
> from place to place, depending on what it applies to. For instance
> 
>     class A
>     {
>         const
>         {
>             int x;
>             int f();
>         }
>     }
> 
> This /in fact/ means that the class A has a member variable called x,
> which is a const(int), and a function f, which does not modify
> anything through this. Those are two totally different meanings of
> "const"
> 
> 
>> Every other storage class applies to the declaration, why should const
>> be completely different?
> 
> Functions can't have storage classes. The notion of a function being
> anything other than invariant ... well, it just doesn't happen in
> today's world (though I do remember the old days of self-modifying
> code).
> 
> The storage class of a function's /context/ - that's a different
> thing, and needs a different syntax.

I think this over analyzes things, and it looks for consistency where 
there simply cannot be (and there aren't in C++, either).

> ...and that's all I'm suggesting really. Let the syntax be
> const(this), instead of merely const. (I can't claim credit for that
> idea. Someone else came up with that one. I just like it lots). That
> makes it clear that we're talking about the storage class of the
> function's context, and explicitly names that context as the
> function's "this".

I don't think it adds anything but extra typing.


> My objection to the existing syntax is more or less solely that
>     const int f();
> 
> does not declare that f returns a const int, and I think that all
> newcomers to D will find that /hugely/ confusing.

Const is different in D than in C++, and it will take some getting used 
to for refugees from C++. Anyone who expects it to behave exactly like 
C++ will have difficulty. But if they spend a little time looking at it 
and give it a chance, I think they'll find that it is more consistent, 
intuitive, and usable than C++ const.

Just remember, the const storage class applies to the declaration, not 
the type, and it will make sense.