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.
