get rid of the `.` in tuples & anonymous struct literal syntax

[andrewrk]

I'm not sure if it's possible to do this, but here's an issue at least to document that we tried.

I believe the current problem is that when the parser sees

{ expression

It still doesn't know if this is is a block or tuple. But the next token would either be , making it a tuple, ; making it a block, or } making it a tuple. Maybe that's OK.

Then tuples & anonymous struct literals will be less noisy syntactically and be easier to type.

[SpexGuy]

This would be nicer to type, but the ambiguity with blocks could lead to some unintuitive compile errors. Consider this example:

fn voidFn() void {}

export fn usefulError(foo: bool) void {
    if (foo) {
        voidFn() // forgot semicolon here
    } else {
//  ^ current compile error: expected token ';', found '}' on first token after forgotten semicolon
        voidFn();
    }
}

Here I've forgotten the semicolon on the expression in the if statement, and the compiler gives an error at the first token after the missing semicolon. But with this proposal, the missing semicolon would cause the block to be interpreted as a tuple, equivalent to this code:

fn voidFn() void {}

export fn weirdError(foo: bool) void {
    if (foo) .{
//  ^ error: incompatible types: 'struct:42:15' and 'void'
//  ^ note: type 'struct:42:15' here
        voidFn() // forgot semicolon here
    } else {
//         ^ note: type 'void' here
        voidFn();
    }
}

For a forgotten semicolon, this is a very confusing error to get, especially for someone new to the language who hasn't learned anonymous struct syntax yet. This might be a solvable problem by identifying cases where this parsing is close to ambiguous and improving the error messages that result, but the two interpretations are different enough that it might be difficult to give an error message that is meaningful for both.

[SpexGuy]

Oh, I think there's also an ambiguous case. These two statements are both valid but mean very different things:

fn voidErrorFn() error{MaybeError}!void {}
comptime {
    var x = voidErrorFn() catch .{};
    var y = voidErrorFn() catch {};
}

[andrewrk]

Good point on the ambiguous case, and good explanation in the other comment.

For the ambiguous case I'd be willing to change {} to mean "tuple of 0 values / struct with 0 fields" and find some other way to specify the void value. @as(void, undefined) already works, but is a bit scary. Maybe void{} if #5038 is rejected.

[jakwings]

Mixing blocks and tuples&structs is the very reason I don't like this proposal. I often forgets the brackets .{ } for printf functions but I never forgot the little dot. What new features are blocked by this proposal?

[andrewrk]

What new features are blocked by this proposal?

nothing - this is pure syntax bikeshedding 🚴

[SpexGuy]

I'd be willing to change {} to mean "tuple of 0 values / struct with 0 fields" and find some other way to specify the void value.

Hmm, that would definitely work, but it also might have the side effect of unexpectedly converting

fn voidErrorFn() error{MaybeError}!void {}
export fn foo() void {
    voidErrorFn() catch {
        //commentedOutCall();
    };
}

to

fn voidErrorFn() error{MaybeError}!void {}
export fn foo() void {
    voidErrorFn() catch .{};
}

when the programmer tries to test commenting out that line.

This could potentially be solved, but we would have to go down kind of a strange road. Zig currently makes a distinction for many types of blocks between expressions and statements. The if in x = if (foo) { } else { }; is an expression. As a result, it requires a semicolon. But if (foo) { } else { } is not an expression but a full statement, so it does not require a semicolon. If we changed <expression_evaluating to !void> catch { code block } to a full statement, so it wouldn't require a semicolon, we could then define {} to mean empty block in a statement context and empty struct in an expression context. This would be kind of a weird facet of the language to play into, but it would fix all of the problems I've brought up and replace them with a single weird but consistent thing. In most of the cases I've thought through, this definition can produce a useful error message if you accidentally get the wrong interpretation of {}. But this could still end up being a footgun in comptime code.

[mogud]

Maybe we can change block syntax, #4412

[andrewrk]

OK, I'm convinced to close this in favor of status quo.

Another option - maybe already discussed, I couldn't find any discussion about it yet - is to use [] for the anonymous list literals (and tuples).

[jakwings]

Inspired by ({}) in JavaScript and (0,) in Rust:

Idea No.1:

{}              // empty block -> void
({})            // still empty block -> void
                   because block is also expression instead of statement
{,}             // empty tuple/struct
{a} {a,b} {...} // tuple with N elements
{.a = x, ...}   // struct
{...;}          // block -> void
label: {...}    // block

const a = [_]u8{1, 2, 3};
const a: [3]u8 = {1, 2, 3};
const a = @as([3]u8, {1, 2, 3});
const a = [_]u8{};  // error?
const a = [_]u8{,};
const a = @as([0]u8, {});  // error!
const a = @as([0]u8, {,});

fn multiReturn() anyerror!(A, B) { ... return {a, b}; ... }

Idea No.2:

()              // empty tuple
(,)             // empty tuple
(,a)            // tuple with 1 element
(a,)            // tuple with 1 element
(a, b, ...)     // tuple with N elements

{}              // empty block (asymmetric to tuple syntax)
{,}             // empty struct
{, ...}         // struct
{...}           // block/struct
label: {...}    // block
({})            // still empty block -> void

const a: [_]u8 = (1, 2, 3);
const a = @as([3]u8, (1, 2, 3));

const a: T = {};  // error if T is not void?
const a: T = {,};
const a = @as(T, {});  // error if T is not void?
const a = @as(T, {,});

const a = [_]u8.(1, 2, 3);
const a = T.{};
↑ Rejected :P https://github.com/ziglang/zig/issues/760#issuecomment-430009129

const a = [_]u8{1, 2, 3};
const a = T{};
↑ Don't worry? https://github.com/ziglang/zig/issues/5038

fn multiReturn() anyerror!(A, B) { ... return (a, b); ... }

[SpexGuy]

A really cool but probably bad option is to define the single value of void as the empty struct. This would remove the ambiguity since it doesn't matter if {} is a block or an empty struct, they both evaluate to the value of void! But this could cause a lot of other weirdness, like var x: Struct = voidFn(); causing x to be default-initialized, so it's probably not something we should do.