Is this example found in the "Composite literals" section of Go Spec a joke? // list of prime numbers primes := []int{2, 3, 5, 7, 9, 2147483647}
I checked on the internet and 2147483647 is a prime number (https://en.wikipedia.org/wiki/2,147,483,647), so this element is fine. Best regards Kamil czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a): > You convince me to your point Axel Wagner. At the same time if we look at > examples in Go Spec, I think their can be improved. > "A0, A1, and []string > A2 and struct{ a, b int } > A3 and int A4, func(int, float64) *[]string, and A5 > > B0 and C0 > D0[int, string] and E0 > []int and []int > struct{ a, b *B5 } and struct{ a, b *B5 } > func(x int, y float64) *[]string, func(int, float64) (result *[]string), > and A5" > I mean, first we need to check that A0, A1 and []string are the same type > and after few examples like D0[int, string] is the same as E0, we have > stated []int and []int are the same type. If you convince yourself that A0 > is the same as A1 and both are the same as []string, checking that []int > has the same type as []int is quite trivial. I would prefer that examples > would start from basic cases like []int is []int and []A3 is []int (if this > one is true) and progress to more convoluted like D0[int, string] is E0. > > Best regards, > Kamil > > czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a): > >> Personally, I'd rather add more examples of "self-evidently equal types". >> In my opinion, all the type aliases in that block confuse matters quite a >> bit. >> >> "[]int and []int are identical" is not actually self-evident at all. It >> is self-evident that any sensible definition of type identity *should* make >> them identical. But it's not self-evident that the given definition *does*. >> Spelling that out in the example, means you are nudged to look at the >> definition and see how their identity follows (by finding "Two slice types >> are identical if they have identical element types"). >> >> In fact, whenever you define an equivalence relation, proving that it is >> reflexive is the very first step. And it's not always trivial. For example, >> `==` on `float64` is *not* reflexive. It seems obvious that NaN == NaN >> *should* hold from how it's spelled - but it doesn't. >> >> So, I disagree that the examples should limit themselves to cases where >> it's non-obvious that the two types should be identical. >> >> On Thu, May 4, 2023 at 12:35 PM Kamil Ziemian <kziem...@gmail.com> wrote: >> >>> There is a second such example just below "[]int and []int", but to >>> understand it we need some more type declarations, I listed them below. >>> `type ( >>> A0 = []string >>> A1 = A0 >>> A2 = struct{ a, b int } >>> A3 = int >>> A4 = func(A3, float64) *A0 >>> A5 = func(x int, _ float64) *[]string >>> >>> B0 A0 >>> B1 []string >>> B2 struct{ a, b int } >>> B3 struct{ a, c int } >>> B4 func(int, float64) *B0 >>> B5 func(x int, y float64) *A1 >>> >>> // Unimportant part. >>> )` >>> The line in question is >>> "struct{ a, b *B5 } and struct{ a, b *B5 }" >>> which is true, but again feel out of place. I only start grasping rules >>> of types identity, but I make guess that it should be something like >>> "struct{ a, b *A5 } and struct{ a, b *B5 }" >>> >>> Of course it my just be that I'm just stupid. Feel free to inform me >>> that indeed I have no idea what is going on in the Go Spec. >>> >>> Best regards, >>> Kamil >>> czwartek, 4 maja 2023 o 12:20:35 UTC+2 Kamil Ziemian napisał(a): >>> >>>> Hello, >>>> >>>> In the section "Type identity" of Go Spec we read a list of type >>>> declarations >>>> `type ( >>>> A0 = []string >>>> A1 = A0 >>>> A2 = struct{ a, b int } >>>> A3 = int >>>> A4 = func(A3, float64) *A0 >>>> A5 = func(x int, _ float64) *[]string >>>> >>>> // Part unimportant for my point. >>>> )` >>>> and then we have list of types that are identical. Among them we can >>>> find text >>>> "[]int and []int" >>>> It is obviously true, but feel out of place. I make a humble guess that >>>> authors intended something along the lines >>>> "[]A3 and []int" >>>> Can someone look at this part of Go Spec? I feel that someone make a >>>> mistake, but at the same time humble me saying that there is any mistake >>>> in >>>> the Go Spec is something that I shouldn't do. >>>> >>>> Best regards, >>>> Kamil >>>> poniedziałek, 8 listopada 2021 o 10:59:23 UTC+1 Kamil Ziemian >>>> napisał(a): >>>> >>>>> Thank you Jan Mercl, now I start to understand this rule. >>>>> >>>>> Best >>>>> Kamil >>>>> >>>>> niedziela, 7 listopada 2021 o 19:34:41 UTC+1 Jan Mercl napisał(a): >>>>> >>>>>> On Sun, Nov 7, 2021 at 7:23 PM Kamil Ziemian <kziem...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> > Can anyone give me explicit example when semicolon is omitted in >>>>>> accordance to the second rule and explanation where it should be? I >>>>>> probably see such situations dozens of times, I just not know that they >>>>>> would needed semicolon in some places. >>>>>> >>>>>> I think this is a simple example: >>>>>> https://play.golang.org/p/ZfKxTos6GjY >>>>>> >>>>>> Click "Run" to see the code is valid, then "Format" to watch one >>>>>> semicolon disappear and then "Run" again to see it's still valid >>>>>> code. >>>>>> >>>>> -- >>> >> 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/001d0306-0a43-4680-a03c-3dc87e89dc5an%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/001d0306-0a43-4680-a03c-3dc87e89dc5an%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/e0d97c28-830b-4c46-9d22-8226e564b448n%40googlegroups.com.