any news on const/invariant?

Daniel Keep daniel.keep.lists at gmail.com
Tue Nov 27 17:38:20 PST 2007



Bill Baxter wrote:
> 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.

Only because you say it is.  Pretend we don't have the current C-style
function declaration syntax for a minute.  The example would become:

const int function() foo = () { ... };
const int function() bar = () { ... };

So one would naturally expect this to work:

const
{
    int function() foo = () { ... };
    int function() bar = () { ... };
}

const really *is* a storage class, even for functions.

Really, I could say that const is delicious when barbecued if I decided
to redefine it to mean "chicken;" you can say anything you want when you
change the question. ;)

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

Well, if you extend that logic, there's no reason to expect this to work:

    writefln("Hi!");

After all, we don't really have letters in a computer!  All we have are
numbers.  And even those are really just fixed-length sequences of logic
values.  So clearly, we shouldn't have int, we should have logic[32].
Except we don't have arrays, either, which makes this somewhat inconvient...

You've got to draw the abstraction line *somewhere.*  You're correct in
saying that it's not obvious that you should be able to group by const
when you think of a member function in terms of its implementation.  But
if you think of functions as values just like ints or floats (or indeed
as some special kind of function that magically knows what "this"
means,) then it makes perfect sense.

> 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?

That's a separate issue, and doesn't really factor into this discussion.
 Again, this is a personal style issue.  I love this because it lets me
just go "and the rest is private."  All of my classes are strictly
divided into the public interface, followed by "private:" and the
private interface.  I could tag every single private thing as being
"private," but then it all turns into spaghetti, and I lose the ability
to see clear delineations in the source.

Six of one, half-dozen of the other. :)

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

I really have to agree with you here.  The presence of the 'return'
storage class is interesting... perhaps something similar could be done
to factor out the common parts of const/non-const members?

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

Personally, I'm not too hot on this one.  It looks too much like type
extensions.  I mean, from the "one way to do things" POV, if you can do
that, why do we even have methods in class bodies at all?  You yourself
said earlier:

  "I don't get why we need two ways to express it."

So by your own reasoning, we should abandon the existing member function
syntax entirely, since it would become redundant.

I know a lot of people who hold very... emphatic... opinions on Python's
use of 'self'.  Heck, AFAIK, Guido's removing it from Python 3000.

Again, this is also inconsistent with everything else you can apply
const to.  I don't get why we need different ways of talking about
functions and everything else.

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

Can't really comment since I'm waiting for the D const stuff to come out
so I can play with it.  I can see it being useful for anything that has
clearly delineated const and non-const interfaces.  Again, I think this
is an issue of how you personally like to organise things.

As a side note, one of the truly terrible things about code is that we
have to choose exactly one way of structuring things.  We can either
interleave definitions, or do them in blocks.  Deeply nest modules, or
shallowly nest them.  Pity we can't just click a header and re-sort our
code. :)

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

True, but then this is the only storage class I can think of that *can*
apply to function arguments at all.  Not surprising that no simple,
general way of solving this has presented itself, considering the
problem didn't exist until now.

> --bb

	-- Daniel



More information about the Digitalmars-d mailing list