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.
