Proposal: Better optional and errors

[Darkfllame]

zig's optionals are really useful in a lot of situations, and they really are good features of it, however sometimes it can be a little tricky to work with them, but today I want to pin point the way to handle those.

So first off, the current way of unwrapping an error is with the catch unreachable syntax, but optionals can be unwrapped with the .? so I first propse to add a .! syntax or to remove the .? syntax of optionals (which is surely not happening).

Now, the .? syntax is fine as it is, but it becomes annoying when working with optionals structs containing optional values, optional slices (sometimes, interfacing with C APIs for example), etc... so I would like to propose a way to "upgrade" the orelse syntax and field accessing:

const NestedOptionals = struct {
    optionalField: ?u32,
    optionalField2: ?struct {
        optioanlField3: ?f32,
    },
};

pub fn main() void {
    var nestedVar = NestedOptionals{
        .optionalField = 5,
        .optionalFild2 = null,
    };
    // "old" style unwrapping works as expected
    const myField = nestedVar.optionalField.?;
    // orelse work same as before
    const myField2 = nestedVar.optionalField orelse 0;

    // now, I propose unwrapping chaining
    const myField3 = nestedVar.optionalField2.optioanlField3 orelse 5;
    // extends to: blk: {
        break :blk (nestVar.optionalField2 orelse break :blk 5).optionalField3 orelse 5
    }
    // myField3 would be 5 in this case
}

Notes:

• If the .! syntax is added to the language, the same proposal applies to it too (except, uses catch instead of orelse).
• Unwrap-chaining optionals and errors without a orelse/catch after, still results in a panic just as before.
• Optional chaining would make a nullable value of the end/target type, i.e: @TypeOf(nestedVar.optionalField2.optionalField3) = ?u32

Additional use cases:

• calling a nullable function pointer without a crash on null/extensive syntax: function.?() orelse { . . . }
• like I said before, chaining nullables without a crash or extensive syntax
• getting a pointer to a nullable value or a null pointer, i.e: &myNullableValue.? orelse null instead of &(myNullableValue orelse retur null)
• accessing fields from a nullable var/field with a default value.

[rohlem]

Two notes:

• .! used to be in the language iirc, but was removed in order to encourage the longer catch unreachable. This is to make these places stick out more to readers - simply asserting no error is possible is usually a code smell / sign of . IMO it's better style to instead switch on the error and comment for every case why it is guaranteed to be unreachable in this scenario, so that newly added errors lead to a missing switch case compile error, and if an error does get hit unexpectedly, it becomes easier to compare the commented reasoning against the scenario that did trigger the error.
• It's possible to implement a chained-optional unwrap in userland via a comptime argument of []const u8 using @field. I think the reason it's not in the language already is that a.b.c orelse will silently change code behavior if field b is changed into an optional later on, even if this wasn't the intention when writing the code. The majority of current Zig semantics promote compile errors to add friction any time a structural change like this happens, so that someone reviews all affected places in code. (Just pointing out the current philosophy, not saying we couldn't/shouldn't provide users a choice in this matter.)

[nektro]

making it easier to do catch unreachable is something we explicitly do not want to be encouraged