[go-nuts] Re: An mistake in tip spec?

1. interface { a;b } is intersection. The "Intersection" between two sets means things which exist in both sets simultaneously. 2. interface { a|b } is union. "Union" means a set of things which which exist in set A *or* set B. Quoting from the spec: *"the predeclared type *any* is an alias for

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote: > 1. interface { a;b } is intersection. The "Intersection" between two sets > means things which exist in both sets simultaneously. > 2. interface { a|b } is union. "Union" means a set of things which which > exist in set A

[go-nuts] Re: An mistake in tip spec?

No, the mistake is in your reading of the spec. You are complaining about this line: interface{ int; any } // no specific types (intersection is empty) The spec makes it clear that: 1. "any" is short for "interface {}" 2. "interface {}" has no *specific types* 3. "interface { int; any }" is an

[go-nuts] Re: An mistake in tip spec?

I don't think your conclusion is right. Otherwise, the following code doesn't compile, but it does. type C interface{ int; any } func f[T C](x byte) T { return T(x) } On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote: > No, the mistake is in your reading of the spec.

[go-nuts] Re: An mistake in tip spec?

So to be more specific, I think you're asking why this code works: https://gotipplay.golang.org/p/kuYzzx4EJY1 Sorry, I made a mistake in interpreting the spec. It also says: "The type set of the empty interface is the set of all types." Therefore, the type set of the intersection { int; any } i

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote: > No, the mistake is in your reading of the spec. You are complaining about > this line: > > interface{ int; any } // no specific types (intersection is empty) > > The spec makes it clear that: > 1. "any" is short for "inter

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote: > So to be more specific, I think you're asking why this code works: > https://gotipplay.golang.org/p/kuYzzx4EJY1 > > Sorry, I made a mistake in interpreting the spec. It also says: > > "The type set of the empty interface is

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote: > >> So to be more specific, I think you're asking why this code works: >> https://gotipplay.golang.org/p/kuYzzx4EJY1 >> >> Sorry, I made a mistake in

[go-nuts] Re: An mistake in tip spec?

sorry again. It should be "the type set and specific types of interface{ int; any } are both {int}." On Thursday, January 6, 2022 at 9:45:35 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote: > >> On Thursday, January 6, 2022 at 9:40:49

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote: > >> No, the mistake is in your reading of the spec. You are complaining >> about this line: >> >> interface{ int; any } // no specific types (inter

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote: > >> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote: >> >>> No, the mistake is in your reading of the spec. You are compla

[go-nuts] Re: An mistake in tip spec?

@Brian > interface{ int; m() } // *[specific type]* int (but type set is empty because int has no method m) > interface{ int; any } // no specific types (intersection is empty) *[even though the type set is not empty]* As noted in the first paragraph of the spec, the set of specific types is c

[go-nuts] Re: An mistake in tip spec?

And by "first paragraph of the spec" I mean "first paragraph of the Structure of interfaces section of the spec". Apologies. On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote: > @Brian > > > interface{ int; m() } // *[specific type]* int (but type set is empty > because int

[go-nuts] Re: An mistake in tip spec?

I take my argument back, I agree with Brian here. According to the spec "interface{}" is a type element because it contains no methods. So the intersection of the specific types "interface{}" and "int" is an empty set. But the set of specific types is "int". On Thursday, January 6, 2022 at 11:3

Re: [go-nuts] Re: An mistake in tip spec?

• From the definition of type elements , we can see that an embedded interface type is a type element. Therefore, `any` is a type element. • `any` is an alias for `interface{}`, therefore it is a type without any type elements, therefore the set of i

[go-nuts] Re: An mistake in tip spec?

> But the set of specific types is "int". But the *type set* is "int"... On Thursday, January 6, 2022 at 11:57:59 AM UTC-5 Jason Phillips wrote: > I take my argument back, I agree with Brian here. According to the spec > "interface{}" is a type element because it contains no methods. So the > i

Re: [go-nuts] Re: An mistake in tip spec?

On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com wrote: > I don't think your conclusion is right. Otherwise, the following code > doesn't compile, but it does. > > type C interface{ int; any } > > func f[T C](x byte) T { > return T(x) > } > I agree that the compiler and spec seem to disa

[go-nuts] Re: An mistake in tip spec?

It does seem like the spec could be more clear for this specific example. The type set of "interface{ int; m() }" is called out explicitly so the same seems helpful for "interface{ int; any }". On Thursday, January 6, 2022 at 12:00:47 PM UTC-5 Jason Phillips wrote: > > But the set of specific t

Re: [go-nuts] Re: An mistake in tip spec?

On Thursday, 6 January 2022 at 17:13:38 UTC axel.wa...@googlemail.com wrote: > On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com > wrote: > >> I don't think your conclusion is right. Otherwise, the following code >> doesn't compile, but it does. >> >> type C interface{ int; any } >> >> func f[T

Re: [go-nuts] Re: An mistake in tip spec?

On Thu, Jan 6, 2022 at 7:02 PM Brian Candler wrote: > On Thursday, 6 January 2022 at 17:13:38 UTC axel.wa...@googlemail.com > wrote: > >> On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com >> wrote: >> >>> I don't think your conclusion is right. Otherwise, the following code >>> doesn't compile, b

Re: [go-nuts] Re: An mistake in tip spec?

To elaborate a bit about the differences between "the type set" and "the set of specific types" and the purpose of the latter - at least as I understand it: The actual type set is hard to compute, in general , so using it to define

Re: [go-nuts] Re: An mistake in tip spec?

On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts wrote: > > • From the definition of type elements, we can see that an embedded interface > type is a type element. Therefore, `any` is a type element. > • `any` is an alias for `interface{}`, therefore it is a type without any > type e

Re: [go-nuts] Re: An mistake in tip spec?

On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor wrote: > On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts > wrote: > > > > • From the definition of type elements, we can see that an embedded > interface type is a type element. Therefore, `any` is a type element. > > • `any` is an ali

Re: [go-nuts] Re: An mistake in tip spec?

On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner wrote: > > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor wrote: >> >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts >> wrote: >> > >> > • From the definition of type elements, we can see that an embedded >> > interface type is a type

Re: [go-nuts] Re: An mistake in tip spec?

On Thursday, 6 January 2022 at 18:52:30 UTC axel.wa...@googlemail.com wrote: > The actual type set is hard to compute, in general > , so > using it to define the set of allowed operations on a type is impractical. > The easier to

Re: [go-nuts] Re: An mistake in tip spec?

On Thu, Jan 6, 2022 at 9:14 PM Brian Candler wrote: > Is that necessarily true? The spec appears to have an example where the > specific types are a superset of the type set: > > - > Examples of interfaces with their specific types: > ... > interface{ int; m() } // int (but type set is empty

[go-nuts] Go 1.17.6 and Go 1.16.13 are released

Hello gophers, We have just released Go versions 1.17.6 and 1.16.13, minor point releases. View the release notes for more information: https://go.dev/doc/devel/release.html#go1.17.minor You can download binary and source distributions from the Go web site: https://go.dev/dl/ To compile from source

Re: [go-nuts] Re: An mistake in tip spec?

The more I think about it, the more I'm inclined to agree that there is something wrong with the spec (and maybe the idea of sets of specific types in general). Because what's the set of specific types of `interface { int | any }`? From the definition, it should be `int` - the union with an empty s

[go-nuts] Multicast Packets

I have a python script that receives the packets, but when I try and do the same in go I get nothing back. Can someone please take a look? func main() { //udp := "10.239.59.108:14310" //"224.0.31.1/24" //"bond0.181" c, err := net.ListenPacket("udp4", "10.239.59.10

Re: [go-nuts] Re: An mistake in tip spec?

Thanks for raising this issue. This is clearly a bug in the spec, or at the very least "an imprecision". Hopefully this is better: https://go-review.googlesource.com/c/go/+/375799 . The set of specific types is an approximation for the actual type set. In practice we only need to consider those

[go-nuts] Re: Multicast Packets

> > This worked: > func main() { ipv4Addr := &net.UDPAddr{IP: net.IPv4(224, 0, 31, 1), Port: 14310} conn, err := net.ListenUDP("udp4", ipv4Addr) if err != nil { fmt.Printf("ListenUDP error %v\n", err) return } pc := ipv4.NewPacketConn(conn) iface, err := n

Re: [go-nuts] Re: An mistake in tip spec?

Thanks for the reply, gri. The latest generics design and implementation are much more beautiful than I expected, though I still think there are many restrictions. BTW, it looks the following line in spec becomes depreciated now, as now any type could be embedded in interfaces. In a slightly m

[go-nuts] Need some advice on multiple sockets and goroutines

I'm designing an app which will be listening to messages on many sockets. - One goroutine per socket. - Each goroutine will do some processing on the messages to a summary datastructure. Only. That goroutine will be the only one writing to that datastructure - There will be another goroutine th

Re: [go-nuts] Re: An mistake in tip spec?

On Fri, Jan 7, 2022 at 2:35 AM 'gri' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Thanks for raising this issue. This is clearly a bug in the spec, or at > the very least "an imprecision". Hopefully this is better: > https://go-review.googlesource.com/c/go/+/375799 . ISTM this still