What am I missin with const?

[Era Scarecrow]

On Tuesday, 29 January 2013 at 09:45:17 UTC, Timon Gehr wrote:
> On 01/29/2013 10:38 AM, deadalnix wrote:
>> Well I think the error message you propose isn't possible as 
>> it would cause many problems in generic code.
>
> How?
>
>> const applied to the return type should be the way to go. It 
>> is basically what everybody except at first when looking at 
>> the code. But it is probably too late to change that.
>
> The current behavior emerges because the parser treats
>
> const void foo(){}
>
> exactly like
>
> const{
>     void foo(){}
> }

  Somehow that's what I'd prefer, Consistency. If it's an int, 
then these two could be very confusing based on location of 
const. So if const is unattached it is for the whole function

  const int foo() //misleading
  vs
  int foo() const

  However specifying an item that's const will always result in 
the correct const of that type. There's never ambiguity following 
those rules; Although those coming from C++ will need to put the 
extra effort to specify which is const.

  const(int) foo()
  vs
  int foo() const


  That's something that was confusing in C++; you could have 
'const const int foo()' and it would be correct, but it doesn't 
really look right; To make it a little less confusing they split 
it up, but the meaning is still easy to confuse.