any news on const/invariant?

Bill Baxter dnewsgroup at billbaxter.com
Wed Nov 28 12:40:48 PST 2007


Janice Caron wrote:
> 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.

Janice, what are your thoughts about how the 'static' attribute fits 
into that.  I was thinking largely the way you were, but 'static' seems 
to be another example of a "storage class" that doesn't change anything 
about the function per-se, but rather it's parameters.  Just like the 
const "storage class", it mucks with the hidden "this" parameter.

If you're going to allow "static" to modify the 'this' parameter by 
sticking it out in front of a function, then it seems you should allow
const the same courtesy.

--bb



More information about the Digitalmars-d mailing list