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-13724] Character literal not treated as having character type #56121

Closed
swift-ci opened this issue Oct 12, 2020 · 4 comments
Closed

[SR-13724] Character literal not treated as having character type #56121

swift-ci opened this issue Oct 12, 2020 · 4 comments
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

@swift-ci
Copy link
Collaborator

Previous ID SR-13724
Radar rdar://problem/70298049
Original Reporter jumhyn (JIRA User)
Type Bug
Status Resolved
Resolution Invalid
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee jumhyn (JIRA)
Priority Medium

md5: 9f994c14279220de88708b22c35c956b

Issue Description:

In the following code, I would expect the calls to both `bar` and `baz` to succeed, calling the `Character`- and `Double`-based overloads respectively. However, the call to `bar` fails.

extension Character {
    func foo() -> Self { return self }
}

extension Double {
    func foo() -> Self { return self }
}

func bar(_: String) {}
func bar(_: Character) {}

func baz(_: Double) {}
func baz(_: Int) {}

bar(".".foo()) // Error: 'String' has no member 'foo'
baz(0.foo()) // OK
@typesanitizer
Copy link

@swift-ci create

@xedin
Copy link
Member

xedin commented Oct 23, 2020

Unfortunately there is no `Behaves Correctly` resolution but I think this is so, because the default type of a string literal is “String”, since `foo()` returns Self there is only one step to take here is to infer “.” as String to make forward progress. It works for 0 because Double is a fallback default for numeric literal. You'd have to use `"." as Character` to make it work.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Nov 1, 2020

Comment by Frederick Kellison-Linn (JIRA)

@xedin Ah, interesting—I would expect the constraint system to attempt solving this with both `bar` overloads, seeing that the `(String) -> Void` overload fails, then attempt with the `(Character) -> Void` overload and find the "correct" solution. Is it always the case that "forward progress" is acheived first by defaulting a literal type rather than attempting the overload disjunction paths?

@xedin
Copy link
Member

xedin commented Nov 2, 2020

jumhyn (JIRA User) Is it always the case that "forward progress" is acheived first by defaulting a literal type rather than attempting the overload disjunction paths?

Not always, but it depends, on what constraint system looks like, sometime bindings are preferred over disjunctions. I think in this particular case you could make the expression type-check if you made `Character` conform to `ExpressibleByStringLiteral` which it isn't by default, that's another reason why `bar(_: Character)` doesn't work.

@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

3 participants