PS Also, *[]T* and *map[K]V* does not look consistent, so I don''t think this > is a true valid reason:
I didn't mean they are inconsistent. They just don't look consistent at the first glance. суббота, 20 июня 2020 г., 19:06:14 UTC+3 пользователь Denis Cheremisov написал: > > I like it. Poor VSCode users will suffer from the current approach and all > these ((())))) – this thing can't even highlight types of function > parameters. Your variant is a lot (I mean a LOT) more readable > > Also, *[]T* and *map[K]V* does not look consistent, so I don''t think > this is a true valid reason: > > In Go we write []int, not [slice int], and we write map[int]int, not [map >> int int]. >> > > суббота, 20 июня 2020 г., 11:02:05 UTC+3 пользователь Wu Kulics написал: >> >> Thank you for your reply. I did mention this suggestion on [Github]( >> https://github.com/golang/go/issues/36457) before, but then everyone's >> focus was on the backend. >> >> >> >> In the previous map and slice examples, [slice int] and [map int int] are >> just for reference. I think this syntax is very similar to []int and >> map[int]int, which is very suitable for everyone to understand the generic >> design of Go, we do not need to change the previous syntax. >> >> >> >> The design of identifier(type T) will lead to too many () in the end, >> especially when defining the receiver function. This change in readability >> undermines Go's original goal. We still want to see simple and clear code >> on Go, not many (). >> >> >> >> I have studied in detail the generic design of Go proposed by others. So >> far, [identifier T] is the only solution that to avoid <>, without >> increasing the number of characters, without adding keywords, without >> ambiguity, without reducing readability, without increase the workload, and >> continues the original grammatical design. >> >> >> >> I hope this design can attract enough attention, or at least it can cause >> some discussion. >> >> >> >> *发件人**: *Ian Lance Taylor <ia...@golang.org> >> *日期**: *2020年6月20日 星期六 上午3:03 >> *收件人**: *Wu Kulics <kul...@outlook.com> >> *抄送**: *"golan...@googlegroups.com" <golan...@googlegroups.com> >> *主题**: *Re: [go-nuts] Generic syntax suggestions >> >> >> >> On Fri, Jun 19, 2020 at 10:24 AM Wu Kulics <kul...@outlook.com> wrote: >> >> Dear Go Design Team: >> >> >> >> Recently I explored a new generic syntax in the [Feel]( >> https://github.com/kulics-works/feel >> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkulics-works%2Ffeel&data=02%7C01%7C%7C44033f9f1d204eb2584d08d814838012%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637281902309384232&sdata=VGm2RHSKdaISaqpa01InrUlDndPWWaEvAVlUlbcNLB8%3D&reserved=0>) >> >> language that I designed, because Feel borrowed a lot of grammar from Go, >> so this Generic syntax may also have some reference value for Go. >> >> >> >> The `identifier<T>` problem is that it conflicts with comparison >> operators and also bit operators, so I don't agree with this design. >> >> >> >> Scala's `identifier[T]` has a better look and feel than the previous >> design, but after resolving the above conflict, it has a new conflict with >> the index design `identifier[index]`. >> >> For this reason, the index design of Scala has been changed to >> `identifier(index)`. This does not work well for languages that already use >> `[]` as an index. >> >> >> >> In Go's draft, it was declared that generics use `(type T)`, which will >> not cause conflicts, because `type` is a keyword, but the compiler still >> needs more judgment when it is called to resolve the` >> identifier(type)(params) `. Although it is better than the above solutions, >> it still does not satisfy me. >> >> >> >> By chance, I remembered the special design of method invocation in OC, >> which gave me inspiration for a new design. >> >> >> >> What if we put the identifier and the generic as a whole and put them in >> `[]` together? >> >> We can get the `[identifier T]`. This design does not conflict with the >> index, because it must have at least two elements, separated by spaces. >> >> When there are multiple generics, we can write `[identifier T V]` like >> this, and it will not conflict with the existing design. >> >> >> >> Substituting this design into Go, we can get the following example. >> >> E.g. >> >> [image: 手机屏幕的截图 描述已自动生成] >> >> >> >> This looks very clear. >> >> >> >> Another benefit of using `[]` is that it has some inheritance from Go's >> original Slice and Map design, and will not cause a sense of fragmentation. >> >> [image: 手机屏幕的截图 描述已自动生成] >> >> >> >> We can make a more complicated example >> >> [image: 手机屏幕截图 描述已自动生成] >> >> >> >> This example still maintains a relatively clear effect, and at the same >> time has a small impact on compilation. >> >> >> >> I have implemented and tested this design in Feel and it works well. >> >> >> >> I think Go’s current generic syntax will eventually render the code too >> many `()`, so that the readability is destroyed when coding, and the goal >> of simplicity is lost. >> >> >> >> In addition to the way of `[identifier T]`, I have also tested the syntax >> of `<identifier T>`. After doing some special processing on `>>`, it can >> also avoid ambiguity. This is closer to the mainstream `identifier<T>` >> grammar, and it is easier to lower the learning threshold for users of >> other languages. >> >> >> >> Thank you very much for reading this email, I hope it will bring >> reference value to the Go community. >> >> >> >> >> >> Thanks for the suggestion. I feel like I've seen this somewhere before, >> perhaps also from you. >> >> >> >> For me personally, it doesn't feel quite right, for the reasons shown in >> your map and slice rewrite. In Go we write []int, not [slice int], and we >> write map[int]int, not [map int int]. We can talk about what it looks like >> if we write the latter variants, but it's years too late to change the >> language in that way. So while the suggestion does seem workable, it >> doesn't feel quite like Go syntax to me. >> >> >> >> But I would be happy to hear other opinions. Thanks for writing it. >> >> >> >> Ian >> > -- 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/ac5929cc-2bd3-463c-b57e-0755ff9ce97co%40googlegroups.com.
