any news on const/invariant?

Bill Baxter dnewsgroup at billbaxter.com
Tue Nov 27 13:42:53 PST 2007


Walter Bright wrote:
> Chris Miller wrote:
>> When grouping with : or { } it applies to the actual named 
>> declarations it encloses; but if const is applied before the return 
>> type, precedence (the juxtaposition) dictates association with the 
>> return type.
>>
>> This is what I would assume.
> 
> Think about const as applying to the item being declared. Here, foo is 
> being declared, so const applies to the foo. Not its return type.
> 
> It would also completely break the consistency of storage classes if:
> 
> const:
> const { }
> const
> 
> meant different things.

But const on a function isn't really a storage class.  It's a type 
specifier on an implicit parameter.  Although being able to wrap a bunch 
of functions in const{ } may be neat, there's no particular reason to 
expect that you should be able to do that based on what it actually is.

Personally I'm not too wild about big storage class blocks in a class. 
I think it quickly makes the code hard to read.  Consider:

    public:

    const:

    private:

    // am I still const here? how do I turn off const now?

I just don't see the ability to say const{ ... } as a big win at all. 
The real annoyance with C++ const is the redundant methods in both const 
and non-const flavors.  That's the thing to target for elimination.


Here's another thought about syntax for specifying const this:
in methods, make it optional to put a 'this' as a first argument.  So

     int foo(int x) {...}

becomes just a shorthand for the explicit version:

     int foo(this, int x) {...}

Then it's obvoious that you'd write the const version as

     int foo(const this, int x) {...}

It's sort of a halfway between explicit 'this' like in Python, and fully 
implicit 'this' like in C++.

Doesn't do anything for the const{ ... } syntax, but I don't really see 
that syntax as a big win, anyway.  It's really never bothered me in C++. 
  Usually in fact I think const and non-const functions end up being 
more or less interleaved if you write a bunch of typical  getThis(); 
setThis(); getThat(); setThat(); methods.  Having a run of functions 
that are all const isn't all that common.

Also const{...} does nothing to eliminate repeated consts used on other 
parameters besides 'this'.  Consider your typical big-value-type struct 
where you have bunches of functions taking const references like
     opAdd(ref const typeof(this) other_one) {...}
you still have to type all those 'const's.

--bb



More information about the Digitalmars-d mailing list