Re: [go-nuts] Should an assignment from int to a type based on int succeed?

Yes, sorry. Eight years of habit is hard to break. I think I agree with you; a small bit of text in https://golang.org/ref/spec#Type_definitions linking to https://golang.org/ref/spec#Predeclared_identifiers and saying that there exist already defined types may ease this, or the suggestion you

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

Dan: I don't know why you are talking about "named type". The nomenclature is outdated and obsoleted by "defined type". The only reason I see to still use it is so you can make an argument that "it has a name" means "it's a defined type" - which isn't even a correct argument anymore since type

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

> This thread isn't "please help me understand how the language works", it's "does the spec accurately and unambiguously define how the language works". Sure, I'm happy to stick to that. Can you tell me if you agree that the spec is clear on this point: that if I write type MyError interface

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

In https://golang.org/ref/spec#Types a Type is defined in terms of a TypeName a TypeLit or a (Type). A TypeName is what makes a type a named type. This is defined as either an identifier or a qualified identifier. For the discussion here we can ignore the latter. An identifier contains letters and

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

> > 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. Can you tell me where the spec says any of

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

>From a language user's point of view, the following understanding seems to work: - A named ("defined") type has one or more names ("identifiers") - A type definition creates a new named type, distinct from all others - An alias declaration adds a new name to an existing type This does beg the

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

On Fri, May 8, 2020 at 10:58 PM 'Axel Wagner' via golang-nuts wrote: > Well, that's what the nomenclature used to be. It was changed, because the > term got ambiguous and confusing once type-aliases got introduced. Turns out, > it's still confusing because people confuse "defined" and

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

On Fri, May 8, 2020 at 7:32 PM Brian Candler wrote: > Could you explain why error is not a defined type? Is it something > special about "error" specifically, or something about interface types in > general? > First, the disclaimer again: I'm now coming around that there *is* a reading of a

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

Plus there is an explicit assignability rule for interface types: * T is an interface type and x implements T. I don't see why any of this implies that error is not a "defined type". -- You received this message because you are subscribed to the

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

On Friday, 8 May 2020 16:58:01 UTC+1, Axel Wagner wrote: > > I'm happy to report, that I *think* I found an inconsistency with error > not being a defined type: > Could you explain why error is not a defined type? Is it something special about "error" specifically, or something about interface

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

sorry, that last sentence of the second paragraph should be "The structural comparison says they *are* identical". On Fri, May 8, 2020 at 6:19 PM Axel Wagner wrote: > Correct. I don't understand why you are saying that, though. > The argument I'm making is that x and y's *types* (not

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

Correct. I don't understand why you are saying that, though. The argument I'm making is that x and y's *types* (not underlying) types are identical (actually, the argument I *was* making was different, but still had little to do with underlying types). The spec

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

> 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

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

On Fri, May 8, 2020 at 5:57 PM Axel Wagner wrote: > > 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 I don't follow. Type of x is not a defined type and neither is type of y. The underlying type of x is

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

All agreed, Jan. I have not meant to indicate that the definition of "defined type" is incorrect or complicated. The problem lies in the fact that a type like int, that is commonly recognized as a built-in type, happens to be a "defined type". This, plus the fact that a pointer to int is not a

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

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

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

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

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

On Fri, May 8, 2020 at 4:31 PM Christoph Berger 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 >

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

Thank you Jan, this helped me a lot. 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. I

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

On Fri, May 8, 2020 at 3:29 PM Christoph Berger wrote: > So I conclude that the assignment of *int to intp succeeds because *int is > not a defined type and both *int and intp have the same underlying type *int. > > Looking through the ref spec I found a couple of places that mention some >

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

Thanks for the quick reply Jan. So I conclude that the assignment of *int to intp succeeds because *int is not a defined type and both *int and intp have the same underlying type *int. Looking through the ref spec I found a couple of places that mention some defined types (esp., all numeric

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

On Fri, May 8, 2020 at 2:46 PM wrote: > Or do I just fail to see the obvious... 'int' _is_ a defined type. It's predeclared in the universe scope. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop