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/8d935499-5b22-434d-9d15-f108d349a238n%40googlegroups.com.
