On Fri, Mar 6, 2026 at 2:32 AM Denis Cheremisov <[email protected]> wrote: > > How it looks like > > Just a simple construct which doesn't take any new word in its simplest form > > configFile := os.Open(arg.config) else err { > return fmt.Errorf("open config file: %w", err) > } > > could be > > func someCall() (int, string, error) { > // ... > } > > // ... > > x, y := someCall() else err { > // ... > } > > Extended > > An extended form would require a new reserved word (`emit`) > > input := os.Open(arg.input) else err { > slog.Warn("failed to open input file", "input-name", arg.input, "err", > err) > emit os.Stdin > } > > Not just for errors > > var counts map[string]int > // ... > count := counts[key] else { > slog.Warn("missing counter in the blah-blah-blah", "missing-counter", key) > continue > } > > > Pros: > > 100% explicit and promote the right way of error processing. > Just in line with the current philosophy of happy path in priority and the > error path as an important yet step child. More in line actually… > Uniform way to process results + error and just error. Unlike the current > > > file, err := os.Open(name) > if err != nil { > return fmt.Errorf("open config file: %w", err) > } > > vs > > if err := os.Rename(...); err != nil { ... } > > > As you see, this is ready to use deconstruction for Result[T] and Option[T] > types, not just a syntactic sugar for `(…, error)` or `(…, bool)`. Meaning, > it is 100% future proof. > > > Cons: > > Frankly, I don't see any. Besides a holy laziness of course.
Seems pretty similar to https://github.com/golang/go/issues/71203. On this topic, though, note https://go.dev/blog/error-syntax. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVgegEFboE9FA9kgYvg1uKZQpj2zC4b8vrnMbCa2on7tw%40mail.gmail.com.
