[HN Gopher] Patterns: Exhaustiveness, Unconditionality, and Rema...
___________________________________________________________________
Patterns: Exhaustiveness, Unconditionality, and Remainder
Author : 0x54MUR41
Score : 43 points
Date : 2023-05-24 14:17 UTC (8 hours ago)
(HTM) web link (openjdk.org)
(TXT) w3m dump (openjdk.org)
| layer8 wrote:
| > Because this risk is always present with enums, if an
| exhaustive enum switch does not have a match-all clause, then the
| compiler will actually synthesize a default clause that throws an
| exception. This guarantees that the switch cannot complete
| normally without selecting one of the clauses.
|
| This is nice. I've gotten into the habit of writing such a test
| _after_ each `switch` statement, for the reasons described (to
| not disable an exhaustiveness linter warning by presence of a
| default clause). I just hope they make the exception a
| RuntimeException (like an IllegalArgumentException) rather than
| an Error (like a NoSuchMethodError).
|
| However, one disadvantage of the new pattern is that you won't be
| able to do your own custom "unexpected enum value" handling any
| more without also disabling the exhaustiveness check (when
| implementing it in a match-all clause), because the synthesized
| check would otherwise preempt it. This is kind of a drawback.
| There should be an extra syntax for defining a "future case"
| clause.
|
| Well, if they use a dedicated new exception type, I guess you
| could catch that, check that it was thrown from the right place
| (i.e. not thrown from some call within the explicit switch case
| code), and then do your custom handling. But that would be quite
| ugly.
| tester756 wrote:
| This is really good article on one of the most important things
| that is not present in mainstream programming languages:
|
| We really need:
|
| 1 - expressive switch without default section,
|
| 2 - closed enums which aren't just dumb ints
|
| 3 - putting more emphasis on compile time safety instead of
| runtime
| mattpallissard wrote:
| > 1 - expressive switch without default section,
|
| The example the author gives, throwing an error on the default
| section, is a bit contrived. I agree that exhaustiveness checks
| should be pushed into the compiler wherever possible and enums
| are generally less useful than they could be. That said, there
| are many, many times where you actually want to the use the
| default section in a switch statement.
|
| Writing in a strongly typed language where you only have to
| match and handle a few special states out of many would be
| absolutely abysmal without a default. Even something
| straightforward like lexing/tokenizing a simple text based
| structure with things like comments or special metadata would
| get out of hand quickly. Yeah, syntax can help alleviate that
| somewhat, but it's still a lot of unnecessary boiler plate. Not
| to mention it makes the sections much easier to grok at times;
| "Here we only handle X, Y, and Z differently and we pass
| everything else along"
| pgwhalen wrote:
| > The example the author gives, throwing an error on the
| default section, is a bit contrived. I agree that
| exhaustiveness checks should be pushed into the compiler
| wherever possible and enums are generally less useful than
| they could be. That said, there are many, many times where
| you actually want to the use the default section in a switch
| statement.
|
| It might be worth rereading. Goetz/Bierman are not saying
| switch defaults are always useless, they are saying that they
| are often useless. My own experience as a daily Java
| programmer suggests that the example is not at all contrived
| - I'm constantly writing switch defaults that will never run.
|
| > Writing in a strongly typed language where you only have to
| match and handle a few special states out of many would be
| absolutely abysmal without a default.
|
| Personally, I would much prefer being explicit about which
| states the code was written to handle, and have the compiler
| guide me towards asserting that newly added states are valid.
| munificent wrote:
| We shipped Dart 3.0 last week with support for switch
| expressions and complex pattern matching in switches. We also
| managed to get in quite sophisticated exhaustiveness checking.
|
| Whether you consider Dart a "mainstream" language is I guess an
| open question. :)
| JonChesterfield wrote:
| The documentation at https://dart.dev/language/patterns is
| great, thanks
| ctvo wrote:
| Dart is the DSL for Flutter, right?
|
| (I'll check it out. Thanks for sharing!)
| valbaca wrote:
| Other way around. Dart is a generic programming language.
| Flutter is the UI framework built with Dart.
|
| https://dart.dev/
|
| https://flutter.dev/
| ctvo wrote:
| The joke is Dart is only used with Flutter. It's a
| language to configure your Flutter application.
|
| It was not a genuine question. The genuine bits were in
| parentheses.
| klysm wrote:
| I can't tell if you are trying to roast dart or asking a
| genuine question
| vmchale wrote:
| Sum types are much more useful with pattern match
| exhaustiveness checking for sure.
___________________________________________________________________
(page generated 2023-05-24 23:01 UTC)