any news on const/invariant?

Janice Caron caron800 at googlemail.com
Wed Nov 28 12:33:20 PST 2007


On 11/28/07, Walter Bright <newshound1 at digitalmars.com> wrote:
> Because those alternatives all look terrible. And frankly, how could
> anyone be confused about what:
>         const x = 3;
> means? I can't understand throwing that out to improve clarity?

You have misunderstood me. The suggestion is that "const" shall not be
an attribute.

This does not rule out allowing "const x = 3;" being a legal
statement, it only means you have to change the grammar of a
declaration in order to allow it.


> Let me put it another way,
> can you explain the difference between C++ const storage class and C++
> const type constructors? There's a big semantic difference.

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.

However, in C++, if a statement such as "const int x = 3;" occurs at
global scope, then x is invariant. We can call that a storage class if
you want.

The similar looking, but drastically different statement "const int *
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.

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

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.



More information about the Digitalmars-d mailing list