Personally think this way is easier to read. In this way, I wrote a few examples, which may be different from the creator
* For example: define a node type<T> Node struct{ prev *Node<T> data T //data *T next *Node<T> } * Call request var node Node<int> * Let's take another example, such as the maximum value * What to do when different types require the maximum value type maxIntCallback func(one,two int) bool type maxFloat64Callback func(one,two float64 /*float32*/) bool //...other types //If you want to use it, such as a certain function. func intCompare(one,two int,max Max) int //1. one,two := 10,20 max := Compare(one,two,_Max) fmt.Println(max) func _Max(one,two int) int { max := one if max > two{ return max } return two } func intCompare(one,two int,max Max) int { return max(one,two) } //2. one,two := 10,20 var max = Compare(one,two, func(one, two int) int { max := one if max > two{ return max } return two }) * Although the above example can also be done using interfaces, it's like all parameters in Java use Object as the type, so it is always bad. * Here is a generic example type<T> maxCallback func(one,two T) T func<T> compare(one,two T,call maxCallback<T>) T { return call(one,two) } //int one,two := 10,20 compare<int>(one,two,func(one,two int ) int { //... }) //float one,two := 10.0,20.0 compare<float64>(one,two,func(one,two float64 ) float64 { //... }) * In this way, it is easier to read and people-oriented 在 2020年7月15日星期三 UTC+8下午1:06:24,Paul Johnston写道: > > If the generic expression <T> was always attached/constrained to the > "type" or "func" keyword (rather than the type or function name), perhaps > this would decrease the lookahead problems with lexing? For example: > > *type<T> Point struct {* > * x, y int* > * data T* > *}* > > *type<R,S> Transformer interface {* > * Transform(R) S* > *}* > > *func<T> Stringify(s []T) string {* > *}* > > *type<T> Vector []T* > > > > On Tuesday, July 14, 2020 at 10:45:41 PM UTC-6 ren...@ix.netcom.com wrote: > >> My opinion is that every major language (no flames please… lots of >> developers write lots of programs and make money doing it) that supports >> generics uses < > for generic types, so Go should too - since there is no >> reason to deviate from this other than to avoid changes to the parser. >> Seems better to pay this cost once - rather than every Go program that uses >> generics being harder to read for eternity (especially for those readers >> that use a lot of languages). >> >> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor <ia...@golang.org> >> wrote: >> > >> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W. <oneo...@gmail.com> >> wrote: >> >> >> >> This feels a little better, but honestly I'm still all for angle >> brackets or like Watson suggested, guillamets. >> >> >> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 >> >> fn[T1](fn2[T2](fn3[T3](v))) // 2 >> >> fn<T1>(fn2<T2>(fn3<T3>(v))) // 3 >> >> fn«T1»(fn2«T2»(fn3«T3»v))) // 4 >> >> >> >> To me, with a background in C++ and Typescript and a little bit of >> Rust, #3 and #4 are just natural and easier to read. >> > >> > The advantage of parentheses is that the language already uses >> > parentheses for lists in various places. Of course that is also the >> > disadvantage. >> > >> > When considering something other than parentheses, I encourage people >> > to look for objective reasons why one syntax is better than another. >> > It's going to be different from other aspects of the language. So >> > what reason would we have for preferring one syntax over another? >> > >> > For example: >> > >> > Robert already gave reasons why square brackets are better than angle >> brackets. >> > >> > The disadvantage of guillemets is that they are hard to type on many >> > keyboards. So to me either square brackets or angle brackets would be >> > better than guillemets. >> > >> > The disadvantage of a two character sequence such as <: :> is that it >> > is more typing. So again either square brackets or angle brackets >> > seem to me to be better. >> > >> > An example of a reason that square brackets might be a poor choice >> > would be ambiguous parsing, or cases where the code is harder to read. >> > >> > It's true that some other languages use angle brackets, but Go already >> > does many things differently. That is only a minor advantage for >> > angle brackets. To me at least it does not outweigh the >> > disadvantages. >> > >> > In short, please try to provide reasons for a different syntax. "It >> > looks good" is a valid reason, but please try to explain why it looks >> > better than square brackets or parentheses. >> > >> > Thanks. >> > >> > 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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%40mail.gmail.com. >> >> >> >> -- 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/7f63b891-9647-46cd-becc-5a8d7ff10943o%40googlegroups.com.