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

Jump to bottom

[SR-2661] Usability regression re: fatalError() within function literals #45266

Closed
swift-ci opened this issue Sep 15, 2016 · 8 comments
Closed

[SR-2661] Usability regression re: fatalError() within function literals #45266

swift-ci opened this issue Sep 15, 2016 · 8 comments
Assignees
@slavapestov
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 3.0 type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-2661
Radar None
Original Reporter Darkmoon_UK (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Swift 3.0

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

md5: d96afbd5d3223a6d24b62985a71c1cb6

Issue Description:

The transition to using the 'Never' type as the underlying mechanism for no-return functions such as fatalError() has caused a serious usability regression preventing their use within function literals, where it was possible before.

Consider the following cases:

// This compiles in both Swift 2 and 3
func test1() -> Int {
    fatalError()
}

// This compiled in Swift2 but no longer does in Swift 3
let test2 : () -> Int = {
    fatalError()
}

// Compiles in Swift 3
let test2 : () -> Int = {
    if false { return 0 }
    fatalError()
}

I filed a bug report with Apple which was closed as 'intended behaviour' but I am unsatisfied by this answer. The third case in particular highlights this as a complex inconsistency that should be considered for a potential fix, or at least deserves a detailed explanation.
@belkadan
Copy link
Contributor

Yes, the second case seems reasonable to allow.

@belkadan
Copy link
Contributor

What was your Radar?

@swift-ci
Copy link
Collaborator Author

Comment by Christopher Hatton (JIRA)

The ticket number is 28269358.

@belkadan
Copy link
Contributor

Thanks.

@swift-ci
Copy link
Collaborator Author

Comment by Christopher Hatton (JIRA)

Reddit discussion

@slavapestov
Copy link
Member

This should be straightforward to fix, I'll take a look.

The problem stems from the fact that a closure body can either be a series of statements, or a single expression. If it is a single expression, its type must match the return type. The fatalError() call triggers the expression path, leading to a type mismatch.

We already have a special case where if the closure return type is () but the expression type is something else, we treat the closure as a statement, not an expression. Similarly, if the expression type is Never, we should treat the closure body as a statement.

@slavapestov
Copy link
Member

Done: #4951

@swift-ci
Copy link
Collaborator Author

Comment by Christopher Hatton (JIRA)

Thanks Slava! :-D

@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

@slavapestov slavapestov

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 3.0 type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@slavapestov @belkadan @swift-ci @AnthonyLatsis