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

[Adem]

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

The C++ Standard (ISO/IEC 14882, Second edition, 2003-10-15)
says under 6.4.2(2) [see also 5.19]:

case constant-expression :

I propose that the case expression of the switch statement
be changed from "integral constant-expression" to "integral expression".
This opens up many new possibilities since then also function calls
would be permitted in the case expression.
The old case case would continue to function since
it is a subset of the new case case.

Example usage:

//...
int f()
{
//...
return BLA1;
}

int g()
{
//...
return BLA2;
}

int h()
{
//...
return BLA3;
}

int y, x = f();
switch (x)
{
case 123 : y = g(); break;
case g() : y = 456; break; // using new case feature, ie. func-call
case h() : y = 789; break; // ditto
default : y = -1; break;
}

[Hendrik Schober]

Keith Thompson wrote:

Hendrik Schober <sp******@gmx.dewrites:

>Keith Thompson wrote:

>>Hendrik Schober <sp******@gmx.dewrites:
Keith Thompson wrote:

[...]

>>>>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.

Since you snipped my argument, I have no idea why you disagree with
it.

Funny. My newsreader still shows it.

Schobi

[Keith Thompson]

Hendrik Schober <sp******@gmx.dewrites:

Keith Thompson wrote:

>Hendrik Schober <sp******@gmx.dewrites:

>>Keith Thompson wrote:
Hendrik Schober <sp******@gmx.dewrites:
Keith Thompson wrote:

[...]

>>>>>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.

Since you snipped my argument, I have no idea why you disagree with
it.

Funny. My newsreader still shows it.

I was referring to the text you replaced with "[...]".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[vippstar]

On Oct 31, 10:56 am, Hendrik Schober <[e-mail]:

Keith Thompson wrote:

Hendrik Schober <[e-mail]:

Keith Thompson wrote:
"[e-mail]" <[e-mail]:
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.

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.

[Hendrik Schober]

vi******@gmail.com wrote:

On Oct 31, 10:56 am, Hendrik Schober <[e-mail]:

>Keith Thompson wrote:

>>Hendrik Schober <[e-mail]:
Keith Thompson wrote:
"[e-mail]" <[e-mail]:
>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?

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

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.

Schobi

[Keith Thompson]

Hendrik Schober <sp******@gmx.dewrites:

vi******@gmail.com wrote:

>On Oct 31, 10:56 am, Hendrik Schober <[e-mail]:

>>Keith Thompson wrote:
Hendrik Schober <[e-mail]:
Keith Thompson wrote:
>"[e-mail]" <[e-mail]:
>>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.

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Hendrik Schober]

Keith Thompson wrote:

Hendrik Schober <sp******@gmx.dewrites:
[...]

> 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.

What would be a corresponding non-abuse?

Schobi

[James Kuyper]

Hendrik Schober wrote:

Keith Thompson wrote:

>Hendrik Schober <sp******@gmx.dewrites:
[...]

>> 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.

What would be a corresponding non-abuse?

if(isupper(c))