Date: Wed, 22 Feb 2023 12:30:30 +0100
On Wednesday, 22 February 2023 11:33 MET, Ville Voutilainen via Std-Proposals wrote:
>> 3) This is not specific to this proposal. Imagine a series of functions called in a chain which all take in a non-const glvalue and modify its value. If you declare the input value -- which is declared in another file far away -- const, everything breaks. If you wanted to double-ensure the typeness of a dependent name, you could still use the `typename` keyword.
>>
>> I can totally understand your concerns about code clarity and readability but i think they don't justify forcing the programmer to introduce redundancy that could be avoided (like making the `override` keyword obligatory).
>> In my opinion, if you find yourself in the situation where it would be ambiguous if a name describes a type or a value, the problem lies in your code, not in the language itself.
>
> Well, the concern in (3) isn't about cases where action-at-a-distance
> makes your code ill-formed. It's about cases where your code
> continues to compile, but with a different meaning.
Oh, now I see. This is actually worse than non-compiling code. Although I can't imagine a situation where one would change a type requirement to a value requirement, combined with all of your other ideas, this is a bad idea.
Case closed.
Sincerely,
Christoph Meyer
>> 3) This is not specific to this proposal. Imagine a series of functions called in a chain which all take in a non-const glvalue and modify its value. If you declare the input value -- which is declared in another file far away -- const, everything breaks. If you wanted to double-ensure the typeness of a dependent name, you could still use the `typename` keyword.
>>
>> I can totally understand your concerns about code clarity and readability but i think they don't justify forcing the programmer to introduce redundancy that could be avoided (like making the `override` keyword obligatory).
>> In my opinion, if you find yourself in the situation where it would be ambiguous if a name describes a type or a value, the problem lies in your code, not in the language itself.
>
> Well, the concern in (3) isn't about cases where action-at-a-distance
> makes your code ill-formed. It's about cases where your code
> continues to compile, but with a different meaning.
Oh, now I see. This is actually worse than non-compiling code. Although I can't imagine a situation where one would change a type requirement to a value requirement, combined with all of your other ideas, this is a bad idea.
Case closed.
Sincerely,
Christoph Meyer
Received on 2023-02-22 11:30:44