On Wed, Apr 26, 2023 at 7:23 AM Andrew Tomazos via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Funnily enough, this exact syntax was considered when pattern matching was
> first discussed. There was a very lengthy discussion about whether to use
> switch or whether to use a new keyword (like inspect), and one of the ways
> that was suggested in the switch case was to use square brackets instead of
> parens to differentiate a pattern switch from a normal switch. The support
> for it was even considerable, but I think the inspect folks won out in the
> end.
>

Interesting, this should have been reflected in the paper so others will be
aware. In any case, this happened very early in the discussion and
probably neither the requirements nor the developments were the same back
then.


>
> On Wed, Apr 26, 2023 at 12:38 PM Barry Revzin via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On Mon, Apr 24, 2023 at 2:09 PM Михаил Найденов via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Hello,
>>> Here is a short proposal to re-use `switch` for Pattern Matching.
>>>
>>
>> Just so I'm clear. The argument is that introducing a new facility, with
>> new semantics, under a new token (whether inspect or match) would be bad
>> for teachability.
>>
>>

> So instead, you're proposing that we reuse an existing token (switch) to
>> introduce two very different behaviors (statement vs expression, best match
>> vs first match, fallthrough vs exactly one arm, integers vs more complex
>> patterns, etc.), but since those different behaviors still need to be
>> differentiated by the parser, you're proposing we do so by simply switching
>> from parentheses to square brackets around the operand? And you're
>> proposing that having 'switch' mean two very different things is better for
>> teachability?
>>
>
That's the issue, it is not different semantically or functionally. Sure
there are nuances, but there are not two different tools that one might
choose one over the other for a particular reason.

We must also consider the negatives by having two similar tools, the
language already has a problem with that in many places, some of
which going back to C like the many loops as an example.

It seems also that the negatives of extending switch are speculative, where
the overlap with switch is objective, more or less.
>From the 4 points you made, I honestly can't think of one that is a problem
in day to day use, with the last two actually being a desired positive.

Last but not least, the problems of introducing a new keyword are not to be
underestimated.
 inspect (...) is basically guaranteed to be used as a function name in
some code and will require some parsing ahead. `match` following the value
will also be hard to do, especially in the case of multiple value (a, b, c,
d) match.

These are problems we create for ourselves out of nowhere, quite literally.
Better, there is a real reason for that, not just worries.



>
>> Doesn't seem like a great idea to me.
>>
>> Barry
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Няма
вирусиwww.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>