January 29, 2013 Re: What am I missin with const? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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.
|
January 30, 2013 Re: What am I missin with const? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Era Scarecrow | On 29/01/2013 10:21, Era Scarecrow wrote:
> 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
There is unnecessary syntactic ambiguity for users unaware of the problem (or aware users that are tired so not able to recognize the problem immediately). This is exactly the same reason dmd warns about a dangling else:
if (x)
if (y){}
else {} // warning: dangling else
The above is consistent and correct code from the compiler's point of view, but is bug-prone for humans, so the compiler complains. The fact it comes up in the newsgroups periodically is proof the current syntax is confusing.
|
Copyright © 1999-2021 by the D Language Foundation