-
Notifications
You must be signed in to change notification settings - Fork 571
Drop support for ad-hoc case ... of expressions
#4241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop support for ad-hoc case ... of expressions
#4241
Conversation
|
The examples are not correct. There is an offside rule in case expressions, where the case branches must be indented past the pattern (just like with It's the same issue as |
| @@ -0,0 +1,20 @@ | |||
| * Remove ad-hoc same-line single-branch case statements | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not single line case statements. Single line case statements are ok. It's a particular form of non-single-line case statements when there's only one branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, a nit, but they are case expressions, not statements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reworked the entry. How about now?
case ... of expressions
|
I'm personally OK with this, but the original ticket asked for a warning before removing. I think we should only remove it without a warning if the other contributors agree to it. |
|
I'll update this to add a warning. |
| | WarnDeprecatedConstraintInForeignImportSyntax | ||
| | WarnDeprecatedKindImportSyntax | ||
| | WarnDeprecatedKindExportSyntax | ||
| | WarnDeprecatedCaseOfOffsideSyntax |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had no idea what to call this error, so this is what I put for now. Let me know if you have a better idea for it.
| WarnDeprecatedKindExportSyntax -> | ||
| "Kind exports are deprecated and will be removed in a future release. Omit the 'kind' keyword instead." | ||
| WarnDeprecatedCaseOfOffsideSyntax -> | ||
| "An expression that is not indented past its `case ... of` branch's binder is deprecated and will be removed in a future release. Indent the expression beyond its binder, similar to how let bindings work." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems verbose, but not sure how else to explain this. Again, up for feedback here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to reference let. Maybe something like:
Dedented expressions in case branches are deprecated and will be removed in a future release. Indent the branch's expression past it's binder instead.
It's a tough concept to word succinctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warning has been updated to use the above rendering. Thanks!
| {% addWarning (let (a,b) = whereRange $8 in [a, b]) WarnDeprecatedCaseOfOffsideSyntax *> pure (ExprCase () (CaseOf $1 $2 $3 (pure ($5, Unconditional $6 $8)))) } | ||
| | 'case' sep(expr, ',') 'of' '\{' sep(binder1, ',') '\}' guardedCase | ||
| { ExprCase () (CaseOf $1 $2 $3 (pure ($5, $7))) } | ||
| {% addWarning (let (a,b) = guardedRange $7 in [a, b]) WarnDeprecatedCaseOfOffsideSyntax *> pure (ExprCase () (CaseOf $1 $2 $3 (pure ($5, $7)))) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need both a and b source tokens here? Or just a?
|
CI error seems related to a |
src/Language/PureScript/Errors.hs
Outdated
| CST.WarnDeprecatedForeignKindSyntax -> suggest $ "data " <> CST.printTokens (drop 3 toks) | ||
| CST.WarnDeprecatedKindImportSyntax -> suggest $ CST.printTokens $ drop 1 toks | ||
| CST.WarnDeprecatedKindExportSyntax -> suggest $ CST.printTokens $ drop 1 toks | ||
| CST.WarnDeprecatedCaseOfOffsideSyntax -> suggest $ CST.printTokens toks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is correct. This is printing a replacement suggestion. This will end up suggesting a replacement of the first and last tokens of the expression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok. I just dropped this by returning Nothing.
Description of the change
Fixes #4012. I think the examples in the changelog entry are correct, but correct me if they're not.
This is for
v0.15.xChecklist: