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

fail statement #677

Closed
gavinking opened this issue Jun 22, 2013 · 4 comments
Closed

fail statement #677

gavinking opened this issue Jun 22, 2013 · 4 comments

Comments

@gavinking
Copy link
Member

Should we introduce a fail statement, that means, approximately, assert (false)? I hate adding a whole new keyword just for this, but it's conceptually useful.

At the very least we should make definite assignment / definite return analysis treat assert (false) as a special case.

@RossTate
Copy link
Member

This sounds more like unreachable in that it's a declaration that this location can't be reached and not a command that if reached it should throw an error.

@FroMage
Copy link
Member

FroMage commented Jun 24, 2013

I'm very doubtful of adding a new keyword just for this. Why not make it a toplevel function of ceylon.language and treat it specially? After all, we already have some special support for Tuple and stuff, why not consider that if we can prove that x() is or is an alias for ceylon.language::fail() then it throws.

Also it reminds me a lot of the throw; we used to have at some point. Not sure how to unify both.

@ghost ghost assigned gavinking Jul 8, 2013
gavinking added a commit that referenced this issue Jul 10, 2013
@gavinking
Copy link
Member Author

Definite return checking now special-cases assert (false).

@gavinking
Copy link
Member Author

Also relevant for definite assignment. Done now.

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