From 10932f211b08ed406f5e25bd723499b6f9a4654d Mon Sep 17 00:00:00 2001 From: Som Snytt Date: Thu, 21 Jun 2018 21:39:49 -0700 Subject: [PATCH] go underscoreless --- _sips/sips/2018-05-26-case-if.md | 40 +++++++++++++++++++++++++------- 1 file changed, 32 insertions(+), 8 deletions(-) diff --git a/_sips/sips/2018-05-26-case-if.md b/_sips/sips/2018-05-26-case-if.md index f246fcfe6c..b9e6200671 100644 --- a/_sips/sips/2018-05-26-case-if.md +++ b/_sips/sips/2018-05-26-case-if.md @@ -14,9 +14,10 @@ redirect_from: /sips/pending/case-if.html ## History -| Date | Version | -|---------------|---------------| -| May 26th 2018 | Initial Draft | +| Date | Version | +|---------------|----------------| +| May 26th 2018 | Initial Draft | +| May 28th 2018 | Underscoreless | ## Motivation @@ -34,18 +35,46 @@ We propose to go underscoreless, pace the famous consultancy. If we can't have SIP-12 then we can have tidy syntax for `if-then` in `case` blocks. +Since `Scala <3` abhors two ways of doing a thing, we eliminate underscore +as a pattern. Underscore as a subpattern, that is, as a `pattern2`, is patterned +after placeholder syntax in expressions, just as constructor patterns are patterned +after constructor invocations. We read `C(_)` and `case C(_) =>` to mean construction +of `C` with an argument unspecified. Similarly, just as placeholder syntax is +restricted, so that an underscore is never an `Expr`, pattern syntax must disallow +underscore as a `Pattern` production. + +In fact, underscore never quite functioned that way, since the definition + + val _ = 42 + +has always incorrectly introduced a variable named `_`. + +Suggestions have surfaced that this syntax should mean something entirely different, +namely, the introduction of a freshly named variable which cannot be named in +source code, but induces the evaluation of the RHS of the definition, and which +can be accessed implicitly if defined as an implicit value. + +However that may be, underscore must first be disallowed as a `Pattern`. + +The only way to coherently define a `case` for which no pattern is applied is to omit +the pattern. And in the absence of alternative semantics, `val _` is not meaningful. +Underscore on the RHS of `var` definitions has already been deprecated, and it is +expected that that syntax will also be removed. + ## Syntax In lieu of 42 match { case _ if now isAfter midnight => nothingGoodHappens() + case _ => () } we write 42 match { case if now isAfter midnight => nothingGoodHappens() + case => () } The syntax accepts either a pattern with optional guard, or a guard with no pattern: @@ -53,11 +82,6 @@ The syntax accepts either a pattern with optional guard, or a guard with no patt CaseClause ::= ‘case’ (Pattern [Guard] | Guard) ‘=>’ Block Guard ::= ‘if’ PostfixExpr -A guard with no pattern is taken as though the pattern were an underscore, which matches -any value. - -This modest proposal eschews dispensing with the pattern altogether, `case =>`. - ## Further Justifications In a respected online [forum][2] which brooks no fools, [Mulliganaceous][3] has posted