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 <javascript:>> > *日期**: *2020年6月20日 星期六 上午3:03 > *收件人**: *Wu Kulics <kul...@outlook.com <javascript:>> > *抄送**: *"golan...@googlegroups.com <javascript:>" < > golan...@googlegroups.com <javascript:>> > *主题**: *Re: [go-nuts] Generic syntax suggestions > > > > On Fri, Jun 19, 2020 at 10:24 AM Wu Kulics <kul...@outlook.com > <javascript:>> 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/3dbf9349-ffa1-4cf3-9bca-fba400a39999o%40googlegroups.com.
