FYI I went ahead and filed https://github.com/golang/go/issues/51145
On Fri, Feb 11, 2022 at 4:57 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > On Fri, Feb 11, 2022 at 3:14 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 >> > > Yes. It is clear why the parser would try and parse it as an array type > declaration. > But as you observed, it doesn't do that in go 1.18 - otherwise it would > output the error message of "invalid array bound". > I can't see a syntactical ambiguity, though. The series of tokens `type A > [ B ] C` can, AFAICT, only be parsed as an array type declaration, generics > or not (if there where *two* identifiers in the brackets, it would be > something else, because that could be a generic type declaration. But not > with one). > > So, to me, this seems like a regression. The parser should parse this as > an array declaration and the type checker should output the helpful error > message, that the array bounds are invalid. > > There are some tests for this error message: > https://github.com/golang/go/blob/master/test/fixedbugs/bug255.go > https://github.com/golang/go/blob/master/test/fixedbugs/issue13485.go > This case is not covered by them, which is probably why this change went > unnoticed. > > I don't know if I should filing the issue. There is already 5k+ issues and >> a lot of work for Go developers, I don't want to add another if there is >> not good enough reasons. > > > This is why I said that this seems like a regression and suggested that > you file an issue. We have an error message for this particular mistake. We > have tests to see that the right error message is printed when it happens. > We clearly care about providing helpful errors. The error message doesn't > appear in a case where it seems that it should. > > All of these surmise to a good reason to file an issue. > > Since this can possible break some code, I heisted about that. Better >> gophers should look at that. >> > > This is purely about changing the error message from the compiler, not > changing whether or not code is being accepted. There is absolutely no > question that `type A[3] int` should continue to compile fine. There is no > question that `type A[float64] int` shouldn't. It's just that the error for > the latter case should include the "invalid array bounds" message. > > Also note that `gofmt` will automatically reformat this code to be clear > about the intention. So, I wouldn't worry about it being unreadable if > people do. > > >> >> Even if writing "type someArrayWithThreeInt[3] int" is evil, wicked >> thing, we know that everything can broke something to someone ( >> https://xkcd.com/1172/) and Go backward compatibility police is quite >> strong. I want to write another 5k+ issue about thing that cannot be >> improved. >> >> Best, >> Kamil >> piątek, 11 lutego 2022 o 14:47:07 UTC+1 Kamil Ziemian napisał(a): >> >>> Axel I agree that "But there is at least some potential benefit to >>> allowing it.". But, by my humble understanding, true question is "Would Go >>> still feel likes Go after this?". This question is one of the reasons why >>> generics was so long, decade or even more, in the making. Somewhere on >>> GitHub there is a discussion about unused type of arguments in the >>> function. I think they agree that with benefits of hindsight you should be >>> force to write func f(_ int) ... for any unused argument, that is need for >>> function signature or some similar reason. But, now this will be to much >>> breaking of backward compatibility with to little benefit. So I think it is >>> worth pondering now, even if we it is already to late to change anything in >>> Go 1.18. >>> >>> "As I said, I'm not 100% yet on whether this is a good idea and much >>> less if that would be enough reason to keep allowing unused type >>> parameters." I like your approach. As I understand your code, because type >>> inference works only on types of arguments, not on types of return values, >>> you define a somepkg.ID to be just a string, that carries information about >>> two additional types. This allows Go type inference algorithm infer type of >>> return value from ID value and put it into place of return type of >>> particular instantiation of generic function. Am I right? >>> >>> You are almost surly more experience Go programmer than me, so anything >>> that I write next may be just silly. Ian Lance Taylor give us one >>> Go-proverb-like advice about generics in Go: "Write code, don't design >>> types". Was your code created according to this rule? It doesn't look like >>> that to me, but I'm in no case someone who should judge it. Better gophers >>> should look at it and decide if this is legitimate use of type parameters. >>> >>> My guts tell me that is not what I want to work with. It is some >>> workaround of type interference algorithm, by putting too much information >>> in one humble string-under-the-hood type. Dave Cheney said once that "Zen >>> of Python" is also valid in Go and maybe better followed by Go programmers >>> than by Python programmers. And this seems to be a breaking of rule >>> "Explicit is better implicit" and, more importantly, of Go proverb "Clear >>> is better than clever". But, again, so true gopher should judge your code, >>> not me. I just write this to start some discussion about that and I >>> remember that you yourself have doubts about it. >>> >>> Best, >>> Kamil >>> piątek, 11 lutego 2022 o 13:56:54 UTC+1 Kamil Ziemian napisał(a): >>> >>>> Thank you Jan Marcel. I see now that I wasn't precise enough. I >>>> understand that '[' and ']' are just tokens, even I have only intuitive >>>> understanding of concept of token. My problem is that as Ian Lance Taylor >>>> and other people said many times: adding generics will make Go more >>>> complicated. My problem is not in understanding why it is more complicated, >>>> but to accept disturbing cases of it becoming so. It less question of >>>> intellectually understanding, more about "feeling of Go". Which is of >>>> course hard to defined. >>>> >>>> I copied compilations errors, because in many cases I don't find Go >>>> compilers errors very useful. Don't get me wrong, in many cases there are >>>> fine, but messages as >>>> > type someDifferentInt[float64] int >>>> > error: float64 (type) is not an expression >>>> are not something that I understand. I often end up ignoring the >>>> message and just stare for few minutes in the line where the error was >>>> found, compare it to working examples, tweak code a little bit and find >>>> what happens. I hope that someone give me some advise how to deal with >>>> that, that Go errors are going to be even harder to me to read. Even if >>>> this advise is "Just accept it and carry on", it will be valuable. >>>> >>>> Best, >>>> Kamil >>>> >>>> piątek, 11 lutego 2022 o 13:38:44 UTC+1 axel.wa...@googlemail.com >>>> napisał(a): >>>> >>>>> On Fri, Feb 11, 2022 at 12:51 PM Kamil Ziemian <kziem...@gmail.com> >>>>> wrote: >>>>> >>>>>> Can someone explain me, why compiler can't throw an error when it >>>>>> find unused type parameter? I like that in Go unused variable, or import, >>>>>> is compile time error and I would appreciate the same behavior with >>>>>> unused >>>>>> type parameters. >>>>>> >>>>> >>>>> I'm not sure it's reason enough, but I do have a case where I want to >>>>> have unused type-parameters on a type. >>>>> Essentially, I have >>>>> >>>>> type ID string >>>>> func Call(ctx context.Context, id ID, req Message) (Message, error) >>>>> >>>>> which does an RPC-like call. It's used as >>>>> >>>>> r, err := framework.Call(ctx, somepkg.ID, somepkg,Request{…}) >>>>> resp := r.(somepkg.Response) >>>>> >>>>> With generics, this would be >>>>> >>>>> type ID string >>>>> func Call[Req, Resp Message](context.Context, ID, Req) (Resp, error) >>>>> >>>>> But this requires writing >>>>> >>>>> resp, err := framework.Call[somepkg.Request, somepkg.Response](ctx, >>>>> somepkg.ID, somepkg.Request{…}) >>>>> >>>>> as return types can't be inferred. Instead, I plan to do >>>>> >>>>> type ID[Req, Resp Message] string // unused type-parameters >>>>> func Call[Req, Resp Message](context.Context, ID[Req, Resp], Req) >>>>> (Resp, error) >>>>> >>>>> which allows `somepkg` to declare >>>>> >>>>> var ID = framework.ID[MyRequest, MyResponse]("my-name") >>>>> >>>>> letting the client write >>>>> >>>>> resp, err := framework.Call(ctx, somepkg.ID, somepkg.Request) >>>>> >>>>> Now somepkg.ID carries both types and is in an argument, so both >>>>> types can be inferred. >>>>> >>>>> As I said, I'm not 100% yet on whether this is a good idea and much >>>>> less if that would be enough reason to keep allowing unused type >>>>> parameters. But there is at least some potential benefit to allowing it. >>>>> >>>>> >>>>>> >>>>>> I need to go for a while, I will go back with more questions about >>>>>> what you can get when using "[]" in Go. >>>>>> >>>>>> Best, >>>>>> Kamil >>>>>> >>>>>> -- >>>>>> 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/b085b991-e59e-4225-a4d6-36b2391e1dc2n%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/golang-nuts/b085b991-e59e-4225-a4d6-36b2391e1dc2n%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/e42ce0ac-a2e9-4caf-8be2-83d75f2a2311n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/e42ce0ac-a2e9-4caf-8be2-83d75f2a2311n%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/CAEkBMfGbAKYFat4T2%3DVy%2BrDW%3DksEzXTZonA0hj63N%3DisuDUaQw%40mail.gmail.com.
