Kamil Ziemian,
// list of prime numbers
primes := []int{2, 3, 5, 7, 9, 2147483647}
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.
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+unsubscr...@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.
