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

Proposal: disallow bare return error union #2562

Open
fengb opened this issue May 27, 2019 · 0 comments
Open

Proposal: disallow bare return error union #2562

fengb opened this issue May 27, 2019 · 0 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@fengb
Copy link
Contributor

fengb commented May 27, 2019

One of the things I like about zig is the explicit control flow. But a slight confusion point arises because current semantics treats return and try as "equals":

fn getUser(postId: u32) !u32 {
    const post = try getPost(postId);
    const author = try getAuthor(post.authorId);
    return author.getUser();
}

We can clearly tell there are 2 lines can error, but the third is ambiguous and requires digging into the getUser definition to confidently say it cannot error. If we disallow bare union returns, this must be converted to return try author.getUser(); which eliminates the guessing game.

At a basic level, requiring an extra 4 characters feels a little silly, but I think the benefits can add up, especially in larger projects with many "tail call" errors.

fn dispatch(action: Action) !Response {
    return switch (action) {
        .Go => doGo(),
        .Stop => doStop(),
        .Jump => doJump(),
        .Stomp => doStomp(),
        .Die => doDie(),
    };
}

// vs

fn dispatch(action: Action) !Response {
    return switch (action) {
        .Go => try doGo(),
        .Stop => try doStop(),
        .Jump => try doJump(),
        .Stomp => doStomp(),
        .Die => doDie(),
    };
}

I don't think this would affect any other language semantics.

@andrewrk andrewrk added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label May 28, 2019
@andrewrk andrewrk added this to the 0.6.0 milestone May 28, 2019
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Jan 5, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 27, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 23, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

2 participants