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.
