On 17 February 2014 06:03, Walter Bright <newshound2@digitalmars.com> wrote:
On 2/16/2014 7:42 AM, Manu wrote:
1. case fall-through is not supported; explicit 'goto case n;' is required.
With this in mind, 'break' is unnecessary. Why is it required?

It's that way to prevent confusion from people used to C/C++, and/or transliterating code from such to D.

I figured that, but deliberately gimping a construct that could be far more useful than it is, just because it was crap in some other language seems like a poor choice to me.

2. 'case 1, 3, 7, 8:' is awesome! ...but ranged cases have a totally different
syntax: 'case 1: .. case 3:'

Why settle on that syntax? The inconsistency looks kinda silly when they appear
together in code.
Surely it's possible to find a syntax that works without repeating case and ':'?

Many syntaxes were proposed for that, and this was the best one.


I'm not sure it's reasonable to use the '..' syntax in this case for that
reason. '..' is an [) range, case ranges must be [] so that it makes sense when
dealing with enum key ranges.

That was the known problem with using a..b

Yeah, but when I suggest a..b, I suggest applying existing [) range rules, as would be expected.

It doesn't make sense for enum keys, and I think the existing syntax is acceptable for [] usage with enum keys, but you're not always switching on enums.
Perhaps supporting both would be useful, where a..b is [) as expected, and 'case A: .. case B:' is [] for use with enums?

3. Why is 'default' necessary? If I'm not switching on an enumerated type, then
many values are meaningless. requiring an empty 'default: break;' line at the
end is annoying and noisy.

It originally was not required, but there was a campaign by a lot of D users to make it required to deal with the common bug of adding a value in one switch statement but forgetting to add it to another corresponding one.

Isn't that the entire point of final switch?
Why introduce final switch to address that, then do this aswell?

if not for these strange decisions (purely for legacy compliance?).

I hope you'll find them less strange now.

Well, I get them, but it seems like an awful lot of missed opportunities. D threatens to improve substantially on C switch, but it only goes half way, resulting in something that's only slightly nicer if used precisely in the 'C way'. 
It doesn't offer any new use cases, which is only really inhibited by some quite trivial decisions.

Maybe a new and improved syntax for D that can be lowered?
'select()'? 'match()'?

I would set it up with proper scoping syntax:
match([x =] expression)
{
  case(1, 3, 4, 6) // use parentheses like all other control statements?
  {
    proper scope block...
    goto named_case;
  }

  case(10..20) // [) interval
    singleStatement();

  case(2, 5, 7..10) // this would be handy too
    singleStatement();
    
  case named_case // it's a useful concept; explicit named case for shared work, which others can jump to. not sure how best to express it...
    sharedOperation();

  default
  {
    // surely this should be optional?
  }
}

I think a really useful construct could be made out of switch, but it seems that it won't happen because it must support C code unchanged.