When you say "var x NillableUint8" then you've just declared a variable of an interface type, and interface types are already nilable, so there's no need for "| nil" in the type!
https://go.dev/play/p/f54akG65qJ3 https://go.dev/play/p/Jmtlta0h9m9 // generic version It's a perfectly valid way of specifying an optional value ("error" works this way, after all). However, I don't think this meets the OP's objective number 3: > 3. It is a compile-time error to use a `T | nil` as a `T` without first checking that it is non-nil. Therefore I think the underlying request a completely different one: that you should never be able to use an interface (or a pointer or a channel, or insert into a map), without first checking that it's not nil, in a way that can be statically validated by the compiler. I'm sure that suggestion has come up before and been discussed to death - e.g. you end up with static types like "a pointer which can never be nil". On Wednesday 20 March 2024 at 07:34:10 UTC Mike Schinkel wrote: > On Mar 19, 2024, at 2:43 PM, Daniel Lepage <dple...@gmail.com> wrote: > > I'm not proposing that *any* value be made nillable, I'm proposing the > explicit syntax > > var x uint8 | nil > > that would create a nillable uint8. A variable of type `byte` would still > only take up one byte; a variable of type `byte | nil` would be larger. > Existing code, which obviously doesn't use the `| nil` syntax because it > doesn't exist yet, would be completely unaffected by this change. > > > Focusing the proposal like that was helpful, at least for me. The > original proposal? tldr; > > Question: Assuming the following was currently possible with type > constraints, how would your proposal differ from the following? > > type NillableUInt8 interface { > > uint8 | nil > > } > > var x NillableUInt8 > > > Also, if the above were possible in future Go, would that achieve the same > objectives you are seeking, or not? And if not, why not? > > Finally, for the Go team, if that would be meet his objectives, would > extending type constraints in this manner be a viable potential? > > > -Mike > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9e78e0c1-81cc-46c0-87ac-5bfd183093aen%40googlegroups.com.
