On Wednesday, March 20, 2024 at 4:14:27 AM UTC-4 Brian Candler wrote:
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!
Well, I was thinking of 1.) explicitness of intent, and 2.) potentially a
signal to the compiler for the use-case.
But you probably have a point.
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.
Hmm. While I did not read the whole proposal at first, my initial takeaway
was that his intent was more about allowing a way for a scalar value to
have an invalid value so it would be possible to determine if a scalar had
been set or not rather than being unsure if zero means *"It was set to 0"*
vs *"It was never set and defaulted to 0."*
Your comments made me go back and read the whole thing, but I was unable to
find a list of enumerated objectives, and I did not find the text you
quoted. Did I miss it somehow?
What I did see is his *"Nice to have"* section which talked about checking
for non-nil. Since he titled it *"nice to have"* I presume he did not
consider that a primary objective of his proposal?
OTOH, even if it is an explicit call-out of `nil` in a type constraint
*could* be the signal for the compiler to enforce that, if that was
something the Go team agreed with that. Still, it is probably too obscure
to be an appropriate signal. ¯\_(ツ)_/¯
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".
I definitely see there is an argument one could make for having the
compiler guarantee against incorrectly using `nil`. But I got the
impression the proposal was motivated by scalars that did not currently
allow `nil` values and not by reference types like pointers, channels and
maps. Although he did not state that explicitly, his examples implied that
to me.
For the compiler to guarantee that an `int` is properly set it needs as a
prerequisite the potential for what it effectively a `nil` state. But
ensuring against a misused `nil` feels to me to be orthogonal to first
allowing an *"unset"* state for scalars.
Or maybe I misread? Maybe the best thing to do is let him tell us what he
was thinking?
-Mike
On Wednesday 20 March 2024 at 07:34:10 UTC Mike Schinkel wrote:
On Mar 19, 2024, at 2:43 PM, Daniel Lepage 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/66a9f1f6-a05d-4fed-b41d-5cfec262fb5bn%40googlegroups.com.
