I'm happy to report, that I *think* I found an inconsistency with error not
being a defined type:
https://play.golang.org/p/gpy6S17wzIM
One of the assignability rules is
> x is a bidirectional channel value, T is a channel type, x's type V and T
have identical element types, and at least one of V or T is not a defined
type.
In this case, T is (say) chan error and V is `chan interface{ Error()
string }`. Neither of them are defined types. So we have to check if V and
T have identical element types.
The rules for type identity are a) A defined type is always different from
any other type - `interface{ Error() string }` is definitely not a defined
type and as stated, `error` also *should not* be one, with the spec as-is.
So this part doesn't take. We then move to b) Two interface types are
identical if they have the same set of methods with the same names and
identical function types. This is clearly the case here.
So, I would argue, that per spec, the program linked above should compile.
And as a corollary, I would argue that the spec should probably also be
amended by "error is a defined type" in the appropriate section. Which
makes things easier, because we can just talk about predeclared types in
general - they are all defined.
(okay, I just realized that technically, the spec says "the type error is
defined as…". Personally, I'd argue that it should specifically use the
term "defined type" or link to the "defined type" section as the sections
on ints/string/bool do, to disambiguate it from the colloquial use of
"defined", if that was intended)
On Fri, May 8, 2020 at 5:42 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> https://golang.org/ref/spec#Type_definitions
> > A type definition creates a new, distinct type with the same underlying
> type and operations as the given type, and binds an identifier to it. […]
> The new type is called a *defined type*. It is different from any other
> type, including the type it is created from.
>
> This seems to imply, when taking as the sole definition of the word
> "defined type", that predeclared identifiers are in fact *not* defined
> types, as they don't originate from a type definition. I agree with
> Christoph here - if you follow any "defined type" link to this definition,
> which is formatted as a definition (italics are a classical typographical
> hint to denote a term being defined), that definition prevents any of the
> predeclared types from being considered "defined types".
>
> However:
>
> https://golang.org/ref/spec#Boolean_types
> > […] The predeclared boolean type is bool; it is a defined type.
> https://golang.org/ref/spec#Numeric_types
> > […] To avoid portability issues all numeric types are defined types […]
> https://golang.org/ref/spec#String_types
> > […] The predeclared string type is string; it is a defined type. […]
> https://golang.org/ref/spec#Errors
> …hmmmmmmmm. I assume it doesn't make a difference here, as it's an
> interface type, so other parts of the spec apply wherever it's important.
> I'll play around for a bit :)
>
> So, while the actual definition *is* ambiguous, the spec as a whole is not
> - it very clearly states that the predeclared types are defined types.
> Note, that the section "predeclared identifiers" itself is not important
> here - being declared and being defined are different words and `errors` is
> predeclared, but, apparently, not defined. Language lawyering this way is
> annoying, but it's also what writing a spec is all about. "defined" and
> "declared" are similar, but distinct terms.
>
> For clarity, it might make sense to amend the definition-looking section
> of the spec with a blurb in the spirit of "defined types are those arising
> from a type definition, or the predeclared types yadayadayada" (where
> yadayadayada could be a list, could be the empty string if we resolve the
> error ambiguity or could be "except error"). That way, if someone uses a
> "defined type" link to see what it means (as Christoph did here for
> assignability) they'll get an immediate answer about the implications.
>
> On Fri, May 8, 2020 at 4:43 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Fri, May 8, 2020 at 4:31 PM Christoph Berger
>> <christophberger....@gmail.com> wrote:
>>
>> > Unfortunately, the connection between "predeclared" (or "implicitly
>> declared" as the first paragraph says) and "defined" is not at all obvious.
>> Especially as the definition of "defined type" refers to types explicitly
>> declared via the "type" keyword.
>>
>> The definition of "defined type" is correct and simple, no special
>> rules exists. The predeclared identifier `int` is declared that way,
>> except it's done by the compiler without the need to do it in user
>> code. See here: https://godoc.org/builtin#int
>>
>> Of course, the builtin package is only a formal definiton, it has
>> special treatment by the compiler, so doing the same in user code
>> would be invalid. Still `int` is defined and treated as `type int
>> something` and it's thus a defined(named) type.
>>
>> In the first approximation, any type represented by a name is a
>> defined type. Later came type aliases, so now it's a bit more
>> complicated b/c one can write also `type T = []U` where T is not a
>> defined type b/c []U is not a defined type.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WzJAWpg4TEcW%2BZ2G-1zcUFNiSS0ezJtz6077Z4U3uwUQ%40mail.gmail.com
>> .
>>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHB2TGOaHPK%2BGVAw3BSEwXm73ajw5wo%2BqCkaN-vv1KR%2BQ%40mail.gmail.com.
