Re: [go-nuts] Cyclic types

2018-05-10 Thread Jan Mercl
On Wed, May 9, 2018 at 7:45 PM Robert Griesemer wrote: > PS: Here's an example where we (humans) can obviously compute the size of a type, yet neither cmd/compile, gccgo, nor go/types have any success in doing so: > > type T struct { > a [10]int > b

Re: [go-nuts] Cyclic types

2018-05-10 Thread Jan Mercl
On Wed, May 9, 2018 at 7:01 PM Robert Griesemer wrote: > I think we also have been hesitant to simply disallow "cyclical types" (per your definition of cyclical) in the spec because we (or at least I) don't have a good understanding that our code actually detects exactly those.

Re: [go-nuts] Cyclic types

2018-05-09 Thread Bakul Shah
I think it is more than a matter of "eager" vs "on-demand" computation. T{} can't be constructed until its size is known. Semantically this is a recursive definition. However, a human may falsely assume that T{} is constructable and given that they may think len(T{}.a) can be computed. If on the

Re: [go-nuts] Cyclic types

2018-05-09 Thread matthewjuran
More accurately: const size = 10 type T struct { a [size]int // many other fields and comments b [size*unsafe.Sizeof(int(0))]int } Matt On Wednesday, May 9, 2018 at 1:56:53 PM UTC-5, matthe...@gmail.com wrote: > > type T struct { > a [10]int > b [len(T{}.a)]int > } > >

Re: [go-nuts] Cyclic types

2018-05-09 Thread matthewjuran
type T struct { a [10]int b [len(T{}.a)]int } could appear about as maintainably like this: const size = 10 type T struct { a [size]int // many other fields and comments b [size]int } This case doesn’t justify more complexity to me. Matt On Wednesday, May 9, 2018 at

Re: [go-nuts] Cyclic types

2018-05-09 Thread 'Robert Griesemer' via golang-nuts
PS: Here's an example where we (humans) can obviously compute the size of a type, yet neither cmd/compile, gccgo, nor go/types have any success in doing so: type T struct { a [10]int b [len(T{}.a)]int } The problem is that all implementations have an "eager" (depth-first) approach somewhere

Re: [go-nuts] Cyclic types

2018-05-09 Thread Robert Griesemer
This sounds all good. I am not disputing at all what you are saying, but a) the spec doesn't actually state any of this explicitly; and b) I agree that size computation is straight-forward once a type data structure is all constructed. The caveat is the 2nd part of this sentence: We're not doing

[go-nuts] Cyclic types

2018-05-09 Thread Jan Mercl
Robert Griesemer wrote in https://github.com/golang/go/issues/25305#issuecomment-387624488 at May 9th: I'm probably using incorrect assumptions. Let me summarize them here: 1) A type is cyclical iff its size is not computable. I'm really not sure if this is what the specification really