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.
