any news on const/invariant?

[Daniel Keep]

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

No, you're not missing anything.  Personally, I blame brain-slippage.

You're correct; the above only vaguely makes sense, and certainly
doesn't mean what I implied it means.

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

Again, I apologise for the snafu on my part.  Honestly, I can't imagine
where I got that from.  Except for the chicken; I happen to rather like
chicken, and it was the tastiest metaphor I could come up with.

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

Well, what about static?  You can apply that to blocks, AFAIK.  Same
thing with extern(X) decorators.

As for the uncost, I was under the impression that 'thing:' blocks did
not stack.  That is,

    private:
    static:
        int foo; // foo is public and static

I would expect the same thing to apply in this case; it would be like
static in that I can't think of any inverse for it.

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

I think this is where I got my thoughts mixed up.  Taking a member
function, the only piece of state this has that you could conceivably
'const'ify is the 'this' pointer.  Although, I admit this is a rather
tenuous link.

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

The way I've understood it is that const is both a type constructor
*and* a storage class.  When invoked with parenthesis, it's a type
constructor.  When invoked without, it's a storage class that happens to
apply the type constructor to whatever the type of the declaration is.

In any case, I retract my argument above since it's clear not even I am
sure what I'm saying. :P  I still *feel* that putting the 'const' out
the front is OK, although I now cannot give you a rational argument for it.

	-- Daniel "this is why I don't post on the NG much..."