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-8766] Allow returning self from instance procedure on an uninhabited type whose return type is that uninhabited type #51274

Open
swift-ci opened this issue Sep 16, 2018 · 2 comments
Open

[SR-8766] Allow returning self from instance procedure on an uninhabited type whose return type is that uninhabited type #51274

swift-ci opened this issue Sep 16, 2018 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-8766
Radar None
Original Reporter neightchan (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 76040ca317b49c0fc1ba64f1a48f8d59

relates to:

  • SR-8434 Don't require a return in functions that take an uninhabited type

Issue Description:

The following code does not compile but should

extension Never {
    var never: Never {
        return self
    }
}

The diagnostic says

Function with uninhabited return type 'Never' is missing call to another never-returning function on all paths
@belkadan
Copy link
Contributor

I'm not sure if this is better or worse than SR-8434.

@swift-ci
Copy link
Collaborator Author

Comment by Nate Chandler (JIRA)

Interesting alternatives.

Thinking of a function as a constructive existence proof (if there is an Input, then there is an Output, and here it is), it seems to make sense to say "if there is an instance self of Never, then there is an instance of Never, namely self". Alternatively, it also seems to make sense (by the principle of explosion) to infer the existence of anything at all. It seems like it's a matter of whether or not the coder chooses to make use of the fact that the impossible has happened (so anything goes). So maybe both should be permitted?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@belkadan @swift-ci