switch()

[Manu]

On 17 February 2014 06:03, Walter Bright <newshound2 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140217/4717740e/attachment-0001.html>