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 <kziemian...@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+unsubscr...@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/CAEkBMfH7kXPiZ9bH_82fGw1DxRapBBABbNvWgVp-AaFUznLrpA%40mail.gmail.com.
