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

Nothing type should affect definite return #1179

Open
lucaswerkmeister opened this issue Jan 4, 2015 · 7 comments
Open

Nothing type should affect definite return #1179

lucaswerkmeister opened this issue Jan 4, 2015 · 7 comments
Assignees
Milestone

Comments

@lucaswerkmeister
Copy link
Member

Nothing die(String? cause = null) {
    // log error
    // send mail to administrator
    throw Exception(cause);
}

String doWork() {
    if (true || false) {
        return "work";
    } else {
        die("Fatal logic error");
    }
}

We can reason that since die returns Nothing, it cannot ever return normally (it could throw, terminate the VM / thread, or never return). Therefore, doWork definitely returns even in the else branch, just like if we inserted a throw; statement there.

The typechecker currently doesn’t do this reasoning, though:

source/tmp/run.ceylon:7: error: does not definitely return: 'doWork' has branches which do not end in a return statement

String doWork() {
      ^

I think this reasoning should be possible, since the flow analysis phase happens after the type assignment phase (see also #891).

And I suppose this could also be applied to definite initialization.

@gavinking gavinking added this to the 1.1.5 milestone Jan 4, 2015
@gavinking gavinking self-assigned this Jan 4, 2015
@gavinking
Copy link
Member

Interesting. Good idea. I never thought of that.

@lucaswerkmeister
Copy link
Member Author

The downside with this is that if people do use this (a powerful die function is the only example I can think of), they’ll get “expression has type Nothing” warnings for perfectly reasonable code. But at least we can disable warnings now, so perhaps that’s not so bad.

@gavinking
Copy link
Member

Well if we did this we could eliminate that warning for the case of an invocation of a function with return type Nothing that is occurs as a statement. It's clear in this case that the function is being called for its side-effect.

@lucaswerkmeister
Copy link
Member Author

Oh, good point. This still discourages stuff like gcc --version > /dev/null || die "No GCC found", which I’ve seen in Bash scripts, but makes much less sense in Ceylon.

@jvasileff
Copy link
Member

I think this would be a great improvement, with many uses. But for the common case, I think #651 would result in much more readable, maintainable, and well documented code.

Edit - ok, I see you're not suggesting this be used in expressions. But I don't see how this wouldn't be at least as confusing, as presented in the initial example, as a "buried" throw in an expression.

gavinking added a commit that referenced this issue Jan 28, 2015
@gavinking
Copy link
Member

Just pushed an experimental implementation of this, but it's not for 1.2.

@lucaswerkmeister
Copy link
Member Author

Now that process.exit() has type Nothing, perhaps disabling the “expression has type Nothing” warning should be something for 1.2? At the moment we get warnings for that in the SDK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants