package main
import "fmt"
/*
Assignability rule #2 (https://golang.org/ref/spec#Assignability):
A value x is assignable to a variable of type T if one of the following conditions applies:
x's type V and T have identical underlying types and at least one of V or T is not a defined type.
*/
type intp *int
type integer int
func main() {
i := 1
var ip1 *int
var ip2 intp
var i2 integer
ip1 = &i // (1) assign *int to *int: ok - expected, both var expressions are of identical type *int
ip2 = &i // (2) assign *int to intp: ok - expected, rule #2 satisfied
i2 = i // (4) assign int to integer: fail - unexpected, rule #2 should allow this:
// underlying type of integer is int and the type of i (int) is not a defined type
// error: ./prog.go:23:5: cannot use i (type int) as type integer in assignment
fmt.Println(ip1, ip2, i2) // avoid "variable declared but not used" error
}
--
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...@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.
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.
I'm happy to report, that I *think* I found an inconsistency with error not being a defined type:
* T
is an interface type and x
implements T
.Could you explain why error is not a defined type? Is it something special about "error" specifically, or something about interface types in general?
Informally, I think of defined types as "named types".
• The section on error *doesn't* specifically point this out. This, really, is where we can argue about reading the spec.- It doesn't use the specific word "defined type" at least and it doesn't link to type definitions, as the other sections doing this. IMO this is an argument that it's not a defined type per spec- However, it does actually use a type definition to define the type, which is an argument that it *is* a defined type per spec (i.e. it conforms to the general definition even without specific mention).
The predeclared type error
is defined as
type error interface { Error() string }
Every name that represents a type and does not stand for a type alias
is a defined, formerly named type. The essence is in the existence of
the name for the type. If it's declared in user code of magically by
the compiler does not matter.
I suspect what has happened here is that it formerly said "named type" in which case it would have been much clearer.
[…]
Again, when it said "named types", that problem would not have existed: it's clear that the type "int" has the name "int".
I don't think that implies there is a specific class of type which is a "predeclared type",
Therefore, I don't think this contradicts the earlier definition of "defined type", and by that definition, I conclude that "error" is a "defined type".
I suppose it could instead say "The predefined type error...", but that would also be confusing because it's not the fact that it's a "defined type" that matters, it's the fact that it has been declared and is available in all scopes.
In my opinion, clarity is not helped by having overlapping terms type definitions and type declarations.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/21dc75e9-ffbd-481c-ae1b-8d8662937d2a%40googlegroups.com.
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.
TypeDef = identifier Type .
The new type is called a fluffy type. It is different from any other type, including the type it is created from.
If you agree with that, […]
However, it does actually use a type definition to define the type, which is an argument that it *is* a defined type per spec (i.e. it conforms to the general definition even without specific mention).
then the question hinges on whether the built-in error interface being "predeclared" somehow emasculates its "defined type" nature
I agree with this apart from "except error", since I still see nothing that says error 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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a6b9729a-2da0-40b9-bfb9-a7714aa6457c%40googlegroups.com.