C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integr

[vippstar]

It wouldn't. [...]

Then I don't see how your above argument is valid.

I'm going to restore mr Thompsons text: (it's where you have [...])

[It wouldn't.] The problem (as I think I've already said in this
thread) is that adding this syntax makes it much easier to check for
characters in the range 'A' to 'Z' *without* making it any easier to
check for characters that are uppercase letters.

It's not the least bit difficult to write bad code in C or C++ (this
is cross-posted), even with their current features, but let's not make
it even easier.

My interprentation:
He says that adding such syntax, .., would introduce more newbie
pitfalls in the language, because most people would expect 'A' .. 'Z'
to mean all the uppercase letters, where it could mean anything.

My view on it: Syntactic sugar that would only complicate the
language(s) further without being a real convenience.

 

[Keith Thompson]

Keith Thompson wrote:
Keith Thompson wrote:
Frankly I think ranges on the case constant expressions would be a
more useful addition while staying with the basic philosophy of the C
switch statement. IOW, "case 2...5:", or something along those
lines. But still not something I'm loosing sleep over...
Then programmers will inevitably write
case 'A' ... 'Z':
which is non-portable (under EBCDIC it matches '\' and '}').
And why exactly would that be worse than an 'if'-'else' chain
relying on ASCII?
It wouldn't. [...]
Then I don't see how your above argument is valid.

[...]
My interprentation:
He says that adding such syntax, .., would introduce more newbie
pitfalls in the language, because most people would expect 'A' .. 'Z'
to mean all the uppercase letters, where it could mean anything.

And wouldn't those be the people who now use 'if' to
do exactly the same?

Probably. But my point, one more time, is that this feature would, in
this particular case, make it *easier* to write bad code (i.e., code
that assumes 'A'-'Z' are contiguous) without making it any easier to
wrote good code (i.e., code that avoids that assumption by using
isupper(), which can't be used in a case expression).

Suppose you're maintaining some code that uses
case 'A' ... 'Z':
and you want to make it more general. You'll have to restructure the
code, using an if statement rather than a switch statement.

On the other hand, if the code you're maintaining uses the equally
non-portable:
if ('A' <= c && c <= 'Z') ...
then it's much more straightforward to change it to:
if (isupper(c)) ...
or perhaps
if (isupper((unsigned char)c)) ...

I'm not saying this is an ironclad argument against adding such a
feature, just that it's a (possibly) significant issue that should be
considered.

On the other hand, it *could* be a real convenience when you need
numeric ranges. It would also be perfectly ok for '0' ... '9', or
even for 'A' ... 'Z' if portability isn't a high priority.

I'm not a string proponent of the feature. I just don't
see the validity of this argument against this.
Any feature added to the language will open new ways to
abusing. If that by itself was an argument against new
features, we wouldn't have had any features at all.

Sure, any feature can be abused; the problem is that this feature
makes certain kinds of abuse easier without making the corresponding
non-abuse any easier.

 

[James Kuyper]

What would be a corresponding non-abuse?

if(isupper(c))