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}
I checked on the internet and 2147483647 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 <[email protected]> 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 <[email protected]>
>>>>>> 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 [email protected].
>>>
>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e0d97c28-830b-4c46-9d22-8226e564b448n%40googlegroups.com.
