On Wed, May 9, 2018 at 7:45 PM Robert Griesemer <g...@google.com> 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 [len(T{}.a)]int > } > The problem is that all implementations have an "eager" (depth-first) approach somewhere leading to requiring all of T to be set up before we can determine the size of T.a. Specifically, when determining > the size of T.b we must be careful to not look at the size of T (which is in the process of being determined), and only at the size of T.a (which we can obviously tell). Furthermore, we must use an > algorithm that computes the size of T.a "on demand", not in the order as the fields appear (otherwise it wouldn't work if b was before a). Sure, as you wrote, size of T.b does not depend on size of T. It depends on len([10]int) only - or the type of T.a in a more general view. I agree with the quoted above completely. Do not compute the size of a struct until needed - that's the only way I can think of how to avoid the (existing) problems of correctly detecting invalid transitively self-referential types. Later on, any possibly unused types will get their sizes determined only after type checking is completed - to ensure they're valid. Exported or not. > All these things make size computation more complicated and expensive. That question is: Is it worth the extra cost? Or are these cases esoteric and don't show up in real code? And if we use simpler > algorithms, is there an easy way to describe which types are accepted and which aren't? It does not sound hard to me to implement it this way. Performance-wise, it'd surprise me to have noticeable higher run-time cost. Actually, not having to construct and maintain the type stack can possibly improve performance (also b/c of less allocations). But I guess it's not trivial to change the existing implementation to the different approach. -- -j -- 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. For more options, visit https://groups.google.com/d/optout.