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-8347] ambiguous subscript when used in “if let" #50875

Closed
johnno1962 opened this issue Jul 23, 2018 · 10 comments
Closed

[SR-8347] ambiguous subscript when used in “if let" #50875

johnno1962 opened this issue Jul 23, 2018 · 10 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@johnno1962
Copy link
Contributor

Previous ID SR-8347
Radar None
Original Reporter @johnno1962
Type Bug
Status Closed
Resolution Done
Environment

Xcode 9.4.1 -> master

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee @gregomni
Priority Medium

md5: 41f20c0680877ef67d4e523a9482b6d5

Issue Description:

I have a struct on which I’d like to define two subscript operations

struct C {

subscript (s: String) -\> String? {

    return ""

}

subscript (s: String) -\> \[String\] {

    return \[""\]

}

}

These are unambiguous if I provide context such as ! or ?? or a type

C()[""] ?? ""

let s1 = C()[""]!

let s2: [String] = C()[""]

But not if I use the expression in an if let which implies the expression must be an optional and gives an error if it’s not.

if let _ = C()[""] {

Ambiguous use of 'subscript'

}

I need to do the following :

if let _ = C()[""] ?? nil {

}

This isn’t the biggest of deals but if an easy way could be found for when an expression is being used in an if let the compiler could propagate a constraint to the type checker that the result needs to be an optional that would be great.

@gregomni
Copy link
Collaborator

I think this is a good idea, and implementing it is fairly straightforward: gregomni@4c6c867

(that's just a proof of concept – a real implementation would have a bunch of tests and assert that you don't try to also pass in a specific contextual type along with the added must-be-optional flag and so on...)

Is this a swift-evolution proposal thing? a go ahead and complete this and pull request thing? or a bad idea for some reason that hasn't occurred to me yet? @xedin or @rudkx thoughts maybe? Thanks!

@johnno1962
Copy link
Contributor Author

Thanks Greg! I’ve checked your patch on my build and this solves the problem I was looking at. Do you want to file a PR on apple/swift? Let me know if you want me to write a test. I‘m hoping this is more of a bug fix than something that needs to be evolved given the alternative is currently an error. Perhaps it might even sneak under the wire for 4.2…

@gregomni
Copy link
Collaborator

John, I am happy to firm this up and file a PR, and that seems like a reasonable way forward to me. But the Apple people are the ones who get complaints if somebody out there is accidentally depending upon some quirk of the typechecker that changes out from under them, so I'm trying to learn to be slightly more cautious. 🙂

@johnno1962
Copy link
Contributor Author

Agreed, I may be getting ahead of myself. Tweaking the typechecker is an activity for the brave. The first step is to get the PR into the queue and see what the compiler devs think along with a CI test run. Thanks for your help on this!

@rudkx
Copy link
Member

rudkx commented Jul 24, 2018

I also think this is a good idea, don't think it should cause any problems with existing code, and I don't think it would need a full SE proposal, but I think it's reasonable to bring that question up on the Evolution | Discussion forum.

@xedin
Copy link
Member

xedin commented Jul 24, 2018

+1 to @rudkx

@gregomni
Copy link
Collaborator

Cool. Brought up on Evolution | Discussion and PR: #18188

@johnno1962
Copy link
Contributor Author

Great, thanks Greg. Let’s see if someone picks it up.

@johnno1962
Copy link
Contributor Author

Thanks again for the time you put into this Greg. From idle thought to “master" in under a week!

@gregomni
Copy link
Collaborator

Thanks John!

@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
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

4 participants