any news on const/invariant?

[Janice Caron]

On 11/28/07, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
> 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.

I have to agree with you.

But as you mentioned earlier, "static" can't be a type constructor, so
it never leads to (apparent) ambiguity. It's that (apparent) ambiguity
that makes me feel uneasy.

If the precence rules were changed such that in a declaration statement like

    const int f();

the const bound to the int, rather than to the f, then I don't see how
it would break anything else. The only thing is that you'd then need a
different way to say that "this" is const within f. Whether that's
const-at-the-back, like in C++, or const(this), or whatever, it would
be necessary, because you have to have /some/ way of saying that.

Consider:

    const int delegate(int) dg;

What is const here? Under Walter's rules, dg, which is a delegate
(actually a pointer to those machine code bytes, and a pointer to some
function's context) is what we're claiming is const, so dg could never
be assigned, except in the declaration itself. How do we declare a
delegate to a const (that is, whose this is const) function? I don't
know. Can it even be done?