any news on const/invariant?

[Bill Baxter]

Daniel Keep wrote:
> 
> 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.

Maybe I'm missing something here, but what exactly are you thinking 
you're making const there?  My understanding is that const applied to a 
method of a class means 'this' is const.  Const applied to a bare 
function or a static method has no useful interpretation AFAIK.

If I'm wrong please correct me.  I haven't been using D2.0 so I don't 
know the nuances of how const works there.


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

I wasn't intending to change the question.  Your response sounds to me 
like you're the one changing the question ... to something about tasty 
chicken.  So please explain again.

>> 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!");

My point was that there is no precedent in the language for something 
like const applying blockwise.  It's a really different kind of beast 
from private/public/protected or from version(){}.  That's not to say we 
can't define it to behave the same way just that there's no entity in 
the language that's exactly like it that *compels* us to say const{...} 
must be allowed in the name of consistency.   If you want to say the 
usage looks kinda like "private" so lets let "const" syntax work 
similarly, then fine, it's a valid argument.  But it's also a valid 
argument to say that const is different enough that it shouldn't work 
the same way as private/public.  In fact there is no 'unconst' so as far 
as I know you won't be able to do 'const:' like you can do 'private:'. 
Unless Walter declares some syntax for it like '!const'.

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

How does it make sense to think of a function as being const without 
considering the actual thing you're promising won't change?  A mere 
function has no 'state' of its own so there's nothing to make constant. 
  Its the data referred to by the function that the function is 
promising not to change.


>> ...

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

Ok there's part of my confusion right there -- I was under the 
impression that const on arguments was classified as a type constructor, 
not a storage class.

But anyway the fact that it is unique in that respect just goes back to 
underscore my point that nothing compels us to go out of our way to 
treat it like every other storage class.  Maybe even calling it a 
storage class is misleading to begin with.  Maybe it is sufficiently 
different that it deserves a different moniker.

--bb