If it helps, I don't think I really understand the generics parts of the spec myself.
On Sat, Jun 10, 2023 at 7:13 PM Kamil Ziemian <kziemian...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/c9e7ce74-34de-4753-80e4-7a41357cb998n%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/CAEkBMfEWP05i_%3DaSMZrRhTHFZWtGDYCEak8y%2BQC3yusYzcrvYQ%40mail.gmail.com.
