Skip to content
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

[SR-8937] Switch over T? fixit does not use syntactic sugar. #51442

Closed
Dante-Broggi opened this issue Oct 7, 2018 · 5 comments
Closed

[SR-8937] Switch over T? fixit does not use syntactic sugar. #51442

Dante-Broggi opened this issue Oct 7, 2018 · 5 comments
Assignees
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers improvement

Comments

@Dante-Broggi
Copy link
Contributor

Previous ID SR-8937
Radar rdar://problem/45216799
Original Reporter @Dante-Broggi
Type Improvement
Status Resolved
Resolution Won't Do
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, DiagnosticsQoI, StarterBug
Assignee @CodaFi
Priority Medium

md5: eb6d4a2aca2f69459d93563fbc38ecaa

Issue Description:

If one has:

enum Foo {
    case bar
    case baz
}


let x: Foo? = .bar
switch x {
case .bar?:
    break
}

There is a fixit to add:

case .none:
    <#code#>
case .some(.baz):
    <#code#>

But a better fixit would be:

case .none:
    <#code#>
case .baz?:
    <#code#>

As that uses existing syntactic sugar.

@AnnaZaks
Copy link
Mannequin

AnnaZaks mannequin commented Oct 12, 2018

@swift-ci create

@CodaFi
Copy link
Member

CodaFi commented Nov 1, 2018

Retracting my previous remarks as it does behave as intended and I misread the diagnostic text.

I will say that this sugar is terser but not necessarily clearer. The Swift Book, for example, does not mention that ? acts as sugar for .some. It's also gonna be hard to format the diagnostic text in general with and without sugar for nested cases.

@CodaFi
Copy link
Member

CodaFi commented Nov 1, 2019

I’ve decided to mark this as NTBF for the reasons above. The ?-style is a terser form of this, but given the choice between undocumented sugar and documented longer form, I’ll always take the latter. This also doesn’t have an impact on diagnostic quality.

@theblixguy
Copy link
Collaborator

You don't need the ? as of Swift 5.1, so I think this should suggest to add bar (and not bar? or .some(.bar) and none cases.

@CodaFi
Copy link
Member

CodaFi commented Nov 2, 2019

I take issue with that for the same reason. We should be spelling the long form since we don't want to have to look back at the way the subject was spelled (it can be an arbitrarily complex expression), and it's up to the user to apply whatever sugar they wish.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers improvement
Projects
None yet
Development

No branches or pull requests

3 participants