On Wed, May 9, 2018 at 7:01 PM Robert Griesemer <[email protected]> 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. 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.
In this particular case it seems to me that we don't need to forbid it
apriori. The contexts in which this definition can appear
1) In a scope where T is not defined:
type T = *T
Covered already, results in 'T undefined'.
2) In a scope where the name T is already declared:
type T int
type T = *T
Covered already by the specs: "No identifier may be declared twice in the
same block, ..."
3) Otherwise T must have been declared in any of the parent scopes:
type T int
func foo() {
var v T
type T = *T
var w T
w = &v // Okay
v = *w // Okay
fmt.Printf("%T %T\n", v, w) // Not nice, but the same
outcome as w/o aliases: https://play.golang.org/p/jgRxFN8qqAL
}
It seems there's no problem in accepting it in this case. sizeof(v) ==
sizeof(int) and sizeof(w) == sizeof(unsafe.Pointer).
> (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).
Agreed. Using the word 'invalid' - as you do later in your post - is much
better and unambiguous.
--
-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].
For more options, visit https://groups.google.com/d/optout.
