It is not a typo
https://go.dev/issue/24451
- sean
On Sat, Jun 3, 2023 at 10:05 PM peterGo <go.peter...@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+unsubscr...@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/CAGabyPq207K2Gij%3D7-TpuaevB1EYPR%2Bqo0NnA7%2B19frmT%2BOWXw%40mail.gmail.com.
