"> 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. 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. Since this can possible break some code, I heisted about that. Better gophers should look at that. 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.
