I'm seriously lost here. Code below works in both Go 1.17 and Go 1.18beta2
> package main
>
> import "fmt"
>
> type someInterface[3] interface {
> SomeMethod()
> }
>
> func main() {
> var varSI someInterface
>
> fmt.Printf("varSI value: %v\n", varSI)
> fmt.Printf("varSI type: %T\n", varSI)
> }
and give in both cases result
> varSI value: [<nil> <nil> <nil>]
> varSI type: main.someInterface
I didn't find any way to assign some new value to "varSI", but this is
already disturbing to me.
Best,
Kamil
piątek, 11 lutego 2022 o 16:00:06 UTC+1 Kamil Ziemian napisał(a):
> "Why is it a sin? It's a perfectly normal type definition. Quite common,
> because useful for attaching methods to a type. One cannotattach a method
> to type [3]int."
> To write it with such white spaces
> > type typeName[3] int
> looks like sinful thing to me. It should be
> > type typeName [3]int
> No problem with that. But, from what I see, both examples works.
>
> Best,
> Kamil
>
> piątek, 11 lutego 2022 o 15:37:59 UTC+1 Jan Mercl napisał(a):
>
>> On Fri, Feb 11, 2022 at 3:13 PM Kamil Ziemian <kziem...@gmail.com>
>> wrote:
>>
>> > "> type someDifferentInt[float64] int
>> > I can't see why the parser can't see that this should (if anything) be
>> interpreted as an array type declaration. To me, this seems like a
>> regression. I'd suggest maybe filing an issue."
>> >
>> > I think I know the reason. You can write
>> > > type someArrayWithThreeInt [3]int
>> > which is proper definition of new type that under the hood is just
>> array of three int. Due to Go rules about names, white spaces and how Go
>> parser work, this is equivalent (I think so) to
>> > > type someArrayWithThreeInt[3] int
>> >
>> > I check this last code in simple example and it seems to work "as you
>> might think". It defines type which under the hood is, again, array of
>> three ints. But writing such thing is probably a sin.
>>
>> Why is it a sin? It's a perfectly normal type definition. Quite
>> common, because useful for attaching methods to a type. One cannot
>> attach a method to type [3]int.
>>
>> > I don't know if I should filing the issue.
>>
>> I wonder what problem is perceived in `type name [expression]T` that
>> would be the essence of the issue?
>>
>> White space between tokens, once the lexer injects the semicolons
>> according to the specified rules, becomes insignificant above
>> separating adjacent tokens, as also defined in the language
>> specification.
>>
>
--
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/315e015d-94d9-4595-b68c-5726d3c12d03n%40googlegroups.com.
