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.
