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-7392] Initializer incorrectly marked as 'throwing' #49935

Closed
swift-ci opened this issue Apr 9, 2018 · 5 comments
Closed

[SR-7392] Initializer incorrectly marked as 'throwing' #49935

swift-ci opened this issue Apr 9, 2018 · 5 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

@swift-ci
Copy link
Collaborator

swift-ci commented Apr 9, 2018

Previous ID SR-7392
Radar rdar://problem/39288282
Original Reporter tonisuter (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Apple Swift version 4.1 (swiftlang-902.0.48 clang-902.0.37.1)
Target: x86_64-apple-darwin17.4.0

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

md5: e91ecbf4610b9a29f828604d6a5394ee

Issue Description:

The following bug was recently discovered / discussed on the Swift Forums (https://forums.swift.org/t/i-dont-know-why-the-compiler-thinks-can-throw/11777):

struct S {
    init(_: () throws -> Void) rethrows {}

    init() {
        // error: call can throw, but it is not marked with 'try'
        self.init({ print("testing") })
    }
}

let s = S({ print("testing") })     // this is fine

In this example, a call to the first initializer should only be considered "throwing" if the function / closure argument is itself "throwing". However, in the second initializer the compiler demands that the explicit call through self.init() is marked with try even though the closure argument is not throwing. This is probably a bug.

@moiseev
Copy link
Mannequin

moiseev mannequin commented Apr 9, 2018

@swift-ci create

@belkadan
Copy link
Contributor

belkadan commented Apr 9, 2018

We probably expected the init syntax to only be used for unapplied constructors and generic contexts. This works, for example:

protocol InitMe {
  init(executing: () throws -> Void) rethrows
}

func test<T: InitMe>() -> T {
  return T.init() {
    print("definitely not throwing")
  }
}

@swift-ci
Copy link
Collaborator Author

Comment by Daryle Walker (JIRA)

I don't know if it makes a difference, but the OP used two initializers of a struct, while I (the OOP) used two initializers across two extensions to a protocol. (Neither initializer was a required one. One initializer's enclosing extension was conditional.) Just something to check during testing.

@belkadan
Copy link
Contributor

super.init is probably also worth checking.

@slavapestov
Copy link
Member

The test case passes in all Swift releases since 5.0. I'll add a regression test just in case.

@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