This is not a complaint, but a reflection. I have read, as careful as I can, the half of the Go Spec and if I didn't learn how parametric polymorphism (generics; did I spell it right) should work from proposals and talks on YouTube, I would probably understand 30% less from it. I know that how parametric polymorphis works in Go and how is described in Spec is not in 100% identical with proposals, but it is good enough. Due to them I have overall picture of what type parameters and related concepts are, so I can guess what is the intention behind part of the Spec that mention type them.
I think I just wouldn't be able learn parametric polymorphism from reading Spec. Things related to it are scattered across the text (this is not a complaint, I just notice a fact) and gathering them together is not a easy task. I should note, that I want to use parametric polymorphism as really as possible. For me this is a feature of the last resort, but one that you should know that exists. Needless to say, I will need to read Spec one more time in the future, at least. Best regards, Kamil sobota, 3 czerwca 2023 o 23:48:52 UTC+2 Sean Liao napisał(a): > It is not a typo > > https://go.dev/issue/24451 > > - sean > > > On Sat, Jun 3, 2023 at 10:05 PM peterGo <go.pe...@gmail.com> wrote: > >> It's a simple typo. Send in a fix. >> >> peter >> >> On Saturday, June 3, 2023 at 4:07:15 PM UTC-4 Kamil Ziemian wrote: >> >>> As burak serdar said, 9 = 3 * 3 is not a prime number, all other >>> elements in the slice are prime numbers. It looks like authors of Go Spec >>> want to make a joke or check how well people read examples in it. >>> >>> Best regards, >>> Kamil >>> sobota, 3 czerwca 2023 o 21:52:37 UTC+2 burak serdar napisał(a): >>> >>>> On Sat, Jun 3, 2023 at 1:40 PM peterGo <go.pe...@gmail.com> wrote: >>>> >>>>> >>>>> Kamil Ziemian, >>>>> >>>>> // list of prime numbers >>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>} >>>>> >>>>> The variable prime is a list of some prime numbers starting with the >>>>> lowest and ending with the highest prime numbers that can safely be >>>>> represented an int. An int may either 32 or 64 bits. >>>>> >>>>> Please explain the joke. >>>>> >>>> >>>> Could it be that 9 is not prime? >>>> >>>> >>>>> >>>>> >>>>> Note: “Explaining a joke is like dissecting a frog. You understand it >>>>> better but the frog dies in the process.” >>>>> ― E.B. White >>>>> >>>>> peter >>>>> On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote: >>>>> >>>>>> 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 <(214)%20748-3647>} >>>>>> >>>>>> I checked on the internet and 2147483647 <(214)%20748-3647> 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...@googlegroups.com. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/22f7a3ec-fb08-498e-9e79-b1759e45b5f2n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/golang-nuts/22f7a3ec-fb08-498e-9e79-b1759e45b5f2n%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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/65d0c91f-af15-4fbc-8d0a-0ce4a162e961n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/65d0c91f-af15-4fbc-8d0a-0ce4a162e961n%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/c9e7ce74-34de-4753-80e4-7a41357cb998n%40googlegroups.com.
