Emeka Nkurumeh

what the first article talks about are sum types which can be achieved through [union types](https://ziglang.org/documentation/master/#union). as for subtypes i don't see how that relates to distinct types. what i...

how is this bloat? having distinct types goes along one of the zens of zig: "communicate intent precisely". this is a proposal for the type system to help catch errors...

because errors are assigned a unique value, how about allowing for tagged unions to use errors as the tag value? this would avoid adding new syntax to language and making...

that's what i wasn't sure about. would you still have to explicitly name the error even when using an inferred error set? or would you just use `error` as you...

in your example `doSomething` can be cleaned up using `errdefer`

related: #786

given we have syntactic sugar already in the form of `optional_pointer.?` would it be possible to make `pub fn foo() void {}` syntactic sugar for `pub const foo = fn()...

@Hejsil according to [this](https://github.com/ziglang/zig/pull/1682#issue-225890405), `optional_pointer.?` was, and still is, syntactic sugar for `optional_pointer orelse unreachable`.

related: #995

wouldn't it be `@Type(TypeInfo.Int{...})` where `TypeInfo.Int` looks like: ```zig pub const Int = struct { is_signed: bool, bits: comptime_int, from: comptime_int, to: comptime_int, }; ``` because of the `@Type` builtin?