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 1:00:34 PM UTC-5, gri 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). And so forth. 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?
>
>
> On Wed, May 9, 2018 at 10:00 AM Robert Griesemer <[email protected]
> <javascript:>> wrote:
>
>> 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 always a correct
>> job of setting up a type completely before it's used. Hence we have issues
>> like #25305. The compiler does a better job than go/types most of the time;
>> but sometimes it's the other way around.
>>
>> 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. We have plenty of examples of code where we could determine the
>> type's size but we still exclude the type. For instance
>>
>> type T = *T
>>
>> T has clearly the size of a pointer, yet we disallow (in the compiler)
>> such types. In this case it's by design (of the type alias proposal), but
>> it would be nice if we could relax it. But I'm not sure we (or I)
>> understand all the consequences fully, quite yet. And I think we have other
>> situations (not involving alias types) where we run into problems, even
>> though we can compute the type's size.
>>
>> (FWIW, I don't think everybody equates "cyclic type" with "type size is
>> not computable". People tend to use "cyclic" and "recursive"
>> interchangeably for types. I was definitively using "cyclic" as "recursive"
>> in #25305).
>>
>> More generally, I think it would be great if we could state exactly what
>> you said in the spec:
>>
>> 1) Types for which their sizes cannot be computed (see 2) are invalid.
>> 2) The size of a type is computable if ... (and then we give essentially
>> the rules you outlined already).
>>
>> As said above, 2) requires all involved types to be set up sufficiently
>> such that we can determine the relevant size information. Sometimes that's
>> not the case. Hence my comment in the issue #25305.
>>
>> Finally, I agree that there shouldn't be a difference between cycle
>> detection by a human and a computer. But the problem is that the computer
>> may be using an algorithm that may be conservative, or incorrect, or not
>> very general (for the sake of speed in the common case).
>>
>> On Wed, May 9, 2018 at 1:21 AM Jan Mercl <[email protected] <javascript:>>
>> wrote:
>>
>>> 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 means. If
>>> not then I wonder why not, because
>>>
>>>
>>> 2) Determining computability of the size of a type is trivial (wrt "we
>>> go through great lengths to detect such cycles").
>>>
>>>
>>> AFAICT, there are two classes of types.
>>>
>>>
>>> In the first (scalar) class the size of T is a constant fully determined
>>> by the kind of T: bool, integers, real and complex types, slices,
>>> interfaces, pointers, maps, channels, functions. (The last three being just
>>> a special case of a pointer.)
>>>
>>>
>>> In the second (non-scalar) class a type T has size dependent
>>> (transitively) on other types (T_1, ... T_n), possibly including T itself.
>>> Scalar T_i brings no problem in computing the size of T.
>>>
>>>
>>> For non-scalar T_i, all we need is a sentinel provided by knowing if the
>>> size of a type is a) not yet determined, b) being determined, c)
>>> determined/valid. When the size of T is needed, but not yet determined,
>>> it's first marked as "being determined". If, during computation of the size
>>> of T, we run into the sentinel, ie. we need to know the size of T_i marked
>>> "size being determined", we have proved the size of T is not computable.
>>> Otherwise the size of T is computed, stored and T is marked as "size
>>> determined/valid".
>>>
>>>
>>> Wrt "even if they are "obviously" not cyclic to a human reader."
>>>
>>>
>>> I think there's no difference between cyclic type determined by a
>>> program or by a human reader except for a bit higher error rate in the
>>> later case ;-)
>>>
>>>
>>> --
>>>
>>> -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 [email protected] <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
