I like Go because it's relatively simple and low-level, like C, except with 
things like garbage collection and channels integrated.  If Go were to have 
"| nil" types then the internal representation of such variables would have 
to be something like this:

type Maybe[T any] struct {
Value T
IsSet bool
}

In which case, why not just use that form explicitly? The code you write is 
then clear and obvious. Taking one of your examples:

func foo3(x Maybe[int]) {
  if x.IsSet {
    fmt.Println("x squared is", x.Value*x.Value)
  } else {
    fmt.Println("No value for x")
  }
}

// https://go.dev/play/p/ci10fhU1zqL

I also think that you need to find multiple compelling use cases (of which 
that example is not one), before fundamentally adding complexity to the 
language. Remember that "nil" is already overloaded in Go, so adding 
another (similar but different) meaning increases complexity for the reader.

Full union types are a different thing again, and I can see the attraction 
of those - except at that point, the language is no longer Go. Having 
"int32 | int64" as a union type, but also as a generic type constraint, 
would also be somewhat mind-boggling. How would you write a type constraint 
that allows a union type?

On Monday 18 March 2024 at 07:01:25 UTC Jan Mercl wrote:

> On Mon, Mar 18, 2024 at 4:41 AM Daniel Lepage <dple...@gmail.com> wrote:
>
> > This change would be entirely backward-compatible ...
>
> Let's consider, for example, the type uint8, aka byte. A variable of
> type byte is specified* to occupy 8 bits of memory and has 256
> possible values. To represent all those values and the new possibility
> of the value being nil, we need 257 distinct values. But that does not
> fit 8 in bits anymore. However, changing the size and/or the bit
> representation of such a variable is observable, making it not
> backwards-compatible.
>
> ----
> *: From https://go.dev/ref/spec#Numeric_types:
>
> """"
> The value of an n-bit integer is n bits wide and represented using
> two's complement arithmetic.
> """"
>

-- 
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/a1e89e97-e879-4bc8-9110-50b8432767bdn%40googlegroups.com.

Reply via email to