> > But I think this is not really worth arguing. If you change fundamental > things like this in the language, then you'll suggesting turning Go into > something that looks like Rust. In which case, you may as well just use > Rust.
I don't think I'm proposing a fundamental change, or to turn Go into Rust - there are good reasons why Go (and the majority of other languages) don't force us to null-check every single pointer access, because there are lots of use cases for pointers besides "this can be null" (e.g. for mutability or performance reasons). I'm proposing a fairly specific syntax to solve a fairly specific (but, at least in projects I've worked on, incredibly common) problem. That said, I do agree that #57644 <https://github.com/golang/go/issues/57644> subsumes this problem (as do a number of other proposals for union or variant types), and if this feature were to be implemented it would definitely be preferable to do so en route to a fuller variant type solution. -- Dan On Thu, Mar 21, 2024 at 11:04 PM Mike Schinkel <m...@newclarity.net> wrote: > Hi Axel, > > Thank you for that link. I had not seen it before, but it is rather > insightful. > > -Mike > > On Wednesday, March 20, 2024 at 10:29:20 AM UTC-4 Axel Wagner wrote: > > FWIW I believe (as Brian sort of points out) this proposal is fully > subsumed under #57644 <https://github.com/golang/go/issues/57644>. Under > that proposal, the proposed type `int | nil` would be spelled `interface{ > int }`. The other syntactical constructs are, as far as I can tell, > identical - you'd have to use a type-assertion to use an `interface{ int }` > as an integer (e.g. to do arithmetic), you can use it with type-switches, > and any `int` as well as `nil` would be assignable to it. > > I think the one difference would be that `x == 42` would work on > `interface{ int }`, but would (presumably) not work on `int | nil`. I > personally doubt that this difference would justify an extra construction, > but I'm mentioning it for completeness sake. > > The "nice to have" of type guards is, I think, an easy idea to mention, > but not an easy idea to add to Go. Note that the other languages mentioned, > that do that, use a function-scoped type-inference (as far as I know) - > that is, they look at an identifiers use over the entire function and then > infer the most general type it would have. > Go has so far tried to avoid doing anything like that, limiting any > inference to the statement (or expression) a value appears in. And this > idea effectively means an identifier would change its type over its > lifetime (from `interface{ int }` - does not allow arithmetic - to `int` - > does allow arithmetic), which would create numerous problems for existing > tooling, as it violates assumptions made by the `go/*` packages. > > On Wed, Mar 20, 2024 at 11:26 AM Mike Schinkel wrote: > > On Wednesday, March 20, 2024 at 5:47:00 AM UTC-4 Brian Candler wrote: > > If you change fundamental things like this in the language, then you'll > suggesting turning Go into something that looks like Rust. In which case, > you may as well just use Rust. > > > Agreed. Which is why I was asking if using interfaces as type constraints > would address the concern. > > And as discussed, probably not. > > But it is an interesting thought exercise. If an interface-based solution > could be found, it would address the concern without turning us effectively > into Rust programmers. ¯\_(ツ)_/¯ > > -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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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/b13c0f3c-2f87-4270-bc57-a22c577473d9n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/b13c0f3c-2f87-4270-bc57-a22c577473d9n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CANtoCQ_ATPoPxbDvCbj30yN0RvS_W8c4qKfQYRpBbTcuEdObiw%40mail.gmail.com.
