On Fri, Feb 11, 2022 at 3:13 PM Kamil Ziemian <kziemian...@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/CAA40n-UOAPY2SGCp_-xnbpj68AXQsHi7qaLtuVKWoHNC_nht6Q%40mail.gmail.com.
