new control flow keyword: result

[andrewrk]

One awkward situation is this pattern:

    const result_is_to = x: {
        if (parsed_from.kind != parsed_to.kind) {
            break :x true;
        } else switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare => {
                break :x !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator);
            },
            WindowsPath.Kind.Drive => {
                break :x asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]);
            },
            else => unreachable,
        }
    };

In all of these situations, we just want to break from the current block.

Proposal: result keyword, which is like break but it always breaks from the current block.

The example becomes:

    const result_is_to = {
        if (parsed_from.kind != parsed_to.kind) {
            result true;
        } else switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare => {
                result !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator);
            },
            WindowsPath.Kind.Drive => {
                result asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]);
            },
            else => unreachable,
        }
    };

[thejoshwolfe]

None of those break statements are breaking from the "current block". The current block is the inner most set of {}, which is the "then" block and the "case" blocks in your example.

We could fix this with a companion keyword to specify which block the result keyword breaks to. With nearly 0 thought put into choosing the actual keyword, here's an iteration on your proposal using block and result as new keywords.

    const result_is_to = block {
        if (parsed_from.kind != parsed_to.kind) {
            result true;
        } else switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare => {
                result !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator);
            },
            WindowsPath.Kind.Drive => {
                result asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]);
            },
            else => unreachable,
        }
    };

Now here's the same thing in status quo zig:

    const result_is_to = while (true) : (unreachable) {
        if (parsed_from.kind != parsed_to.kind) {
            break true;
        } else switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare => {
                break !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator);
            },
            WindowsPath.Kind.Drive => {
                break asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]);
            },
            else => unreachable,
        }
    };

This while (true) : (unreachable) thing doesn't communicate intent very clearly.

[andrewrk]

Better example of the common pattern:

            if (windows.GetExitCodeProcess(self.handle, &exit_code) == 0) x: {
                break :x Term { .Unknown = 0 };
            } else x: {
                break :x Term { .Exited = @bitCast(i32, exit_code)};
            }

[raulgrell]

I think the result keyword is the ideal solution, as it would be semantically equivalent to an implicit block return, but... you know, explicit.

Anything that would require more granular control would be done with the named blocks as currently supported.

[thejoshwolfe]

Ok here's the original example with the "current block" semantics done properly:

    const result_is_to = (
        if (parsed_from.kind != parsed_to.kind)
            result true;
        else switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare =>
                result !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator),
            WindowsPath.Kind.Drive =>
                result asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]),
            else => unreachable,
        }
    );

Or without removing any of the curly braces, and using a minimum number of result keywords:

    const result_is_to = {
        result if (parsed_from.kind != parsed_to.kind) {
            result true;
        } else switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare => {
                result !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator);
            },
            WindowsPath.Kind.Drive => {
                result asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]);
            },
            else => unreachable,
        }
    };

Or putting the result keywords where they are most pertinent, which is where you introduce a new block scope:

    const result_is_to = {
        if (parsed_from.kind != parsed_to.kind) result {
            result true;
        } else switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare => result {
                result !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator);
            },
            WindowsPath.Kind.Drive => result {
                result asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]);
            },
            else => unreachable,
        }
    };

These semantics seem pretty confusing to keep up with. I think I like my while (true) : (unreachable) solution better. Might just be my opinion though.

[raulgrell]

My understanding is that the following examples would be equivalent, the first using only expressions, and the second wrapping every expression in a block:

const result_is_to = if (parsed_from.kind != parsed_to.kind)
    true
else switch (parsed_from.kind) {
    WindowsPath.Kind.NetworkShare => !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator),
    WindowsPath.Kind.Drive => asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]),
    else => unreachable,
};

And with blocks around every expression

const result_is_to = { 
    result if (parsed_from.kind != parsed_to.kind) {
        result true;
    }
    else {
        result switch (parsed_from.kind) {
            WindowsPath.Kind.NetworkShare => {
                result !networkShareServersEql(parsed_to.disk_designator, parsed_from.disk_designator);
            }, 
            WindowsPath.Kind.Drive => {
                result asciiUpper(parsed_from.disk_designator[0]) != asciiUpper(parsed_to.disk_designator[0]);
            },
            else => unreachable,
        };  
    } 
};

I think in these examples the semantics are a bit clearer.

Your while (true) : (unreachable) is actually pretty good though, the semantics are at least more familiar to C (and etc) programmers. We would basically have two kinds of blocks: a "returning block" => block { } and a "scope block" => { }.

All blocks are equal, but some blocks are more equal than others =P

[tjpalmer]

I agree the current situation is awkward. I had to work that out once, and it wasn't super fun. Are any of these many new keyword proposals context sensitive? Or is there some escape for identifiers like in C# (or shell or whatnot)? Just that a lot of good identifier names are getting taken.

[jido]

You could use a closure and return instead of while (true) : (unreachable).