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.

Sign up for GitHub

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

Jump to bottom

[SR-10259] ExpressibleByStringLiteral masks an initializer without any warning in Swift 5. #52659

Closed
YOCKOW opened this issue Apr 2, 2019 · 4 comments
Closed

[SR-10259] ExpressibleByStringLiteral masks an initializer without any warning in Swift 5. #52659

YOCKOW opened this issue Apr 2, 2019 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@YOCKOW
Copy link
Collaborator

YOCKOW commented Apr 2, 2019

Previous ID SR-10259
Radar None
Original Reporter @YOCKOW
Type Bug
Status Resolved
Resolution Invalid
Environment
  • macOS Mojave 10.14.3
  • Swift 5.0, 4.2
Additional Detail from JIRA
Votes 0
Component/s
Labels Bug
Assignee None
Priority Medium

md5: 46af62db6d0b3dc9cc1f14bc6b65eca0

is duplicated by:

  • SR-12034 ExpressibleByStringLiteral initializer called unexpectedly

relates to:

Issue Description:

[Sample Code]

struct MyString: ExpressibleByStringLiteral {
  init?(_ string:String) { print("Failable Initializer.") }
  init(stringLiteral value: String) {}
}

MyString("My String.")
// -> Prints "Failable Initializer." in Swift 4.2
// -> Prints nothing in Swift 5

[Description]

I don't know whether this is a bug or a new feature in Swift5, but, what I expect is...

  • the same behavior with Swift 4.2 if this is a bug

  • some warning about masking if this is a new feature
@belkadan
Copy link
Contributor

belkadan commented Apr 2, 2019

It's a feature: SE-0213. A warning would be inappropriate because the initializer might be satisfying a protocol requirement. You can still get to it explicitly by using MyString.init if you really need to.

@belkadan
Copy link
Contributor

belkadan commented Apr 2, 2019

Sorry, I'll walk that back a bit. If we had such a warning, we'd need a way to silence it as well.

@YOCKOW
Copy link
Collaborator Author

YOCKOW commented Apr 4, 2019

@belkadan

I'm very sorry, but I overlooked the evolution and now I understand it.
I thought that warning about the ambiguity between the default implementation of the language and the initializer defined in the type was meaningful and offenseless especially when the initializer was failable. Certainly, the compiler should warn the people who want to call the initializer, on the other hand, it should not warn the people who want to use Swift's default implementation.
Shamefully, I did not think how to silence the warning in the latter case.
Thank you.

@belkadan
Copy link
Contributor

belkadan commented Apr 4, 2019

Ah, I shouldn't have been so brusque to begin with! Language design is a tricky space because everyone's using a different subset of the language. :-)

@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
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@belkadan @YOCKOW