I agree, I prefer the D syntax as well.
*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*
Easy and readable :)
On Monday, 20 July 2020 at 16:22:08 UTC+2 christoph...@gmail.com wrote:
> I would like to insist on considering the D syntax using the ! for
> generics instantiation.
>
> The first time I saw it, I was puzzled and found it unpleasant. But this
> is just because it is unfamiliar and not intuitive.
> Once I got used to it, I found it much simple than the C++ templates. In
> fact I even found it easier to use than the C++ notation.
>
> The thing is that generic instantiation will be very frequent and most of
> the time with only one template argument. The notation using a simple ! is
> then much lighter and readable then a notation using parenthesis.
>
> Please, consider and favor the readability and code lightness of the most
> frequent use with generics which is the instantiation with one type
> argument.
>
> Compare T!int with T(int) or T[int] or T<int>, or A!B!int with A(B(int))
> or A[B[int]] or A<B<int>>.
>
> Please take the time time to experiment it and optimize the most frequent
> use.
> The D notation gave me the impression that use of generics was simple.
> Much simpler than with C++.
>
> Go generics made a huge and good simplification by dropping the contracts.
> Please, follow the same strategy for the instantiation of generics which
> will be the most frequent occurrence in the code.
>
> Le mardi 14 juillet 2020 à 23:56:01 UTC+2, gri a écrit :
>
>> We have received a variety of feedback on the generics draft design
>> <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md>
>>
>> (blog <https://blog.golang.org/generics-next-step>). Thanks to everyone
>> who took the time to read it, play with generics code in the playground
>> <https://go2goplay.golang.org/>, file issues, and send us their thoughts.
>>
>> Not unexpectedly, many people raised concerns about the syntax,
>> specifically the choice of parentheses for type parameter declarations and
>> generic type and function instantiations.
>>
>> A typical computer keyboard provides four easily accessible pairs of
>> single-character symmetrical "brackets": parentheses ( and ), square
>> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses
>> curly braces to delineate code blocks, composite literals, and some
>> composite types, making it virtually impossible to use them for generics
>> without severe syntactic problems. Angle brackets require unbounded parser
>> look-ahead or type information in certain situations (see the end of this
>> e-mail for an example). This leaves us with parentheses and square
>> brackets. Unadorned square brackets cause ambiguities in type declarations
>> of arrays and slices, and to a lesser extent when parsing index
>> expressions. Thus, early on in the design, we settled on parentheses as
>> they seemed to provide a Go-like feel and appeared to have the fewest
>> problems.
>>
>> As it turned out, to make parentheses work well and for
>> backward-compatibility, we had to introduce the type keyword in type
>> parameter lists. Eventually, we found additional parsing ambiguities in
>> parameter lists, composite literals, and embedded types which required more
>> parentheses to resolve them. Still, we decided to proceed with parentheses
>> in order to focus on the bigger design issues.
>>
>> The time has come to revisit this early decision. If square brackets
>> alone are used to declare type parameters, the array declaration
>>
>> type A [N]E
>>
>> cannot be distinguished from the generic type declaration
>>
>> type A[N] E
>>
>> But if we are comfortable with the extra type keyword, the ambiguity
>> disappears:
>>
>> type A[type N] E
>>
>> (When we originally dismissed square brackets, the type keyword was not
>> yet on the table.)
>>
>> Furthermore, the ambiguities that arise with parentheses appear not to
>> arise with square brackets. Here are some examples where extra parentheses
>> are not needed with square brackets:
>>
>> using () using []
>>
>> func f((T(int)) func f(T[int])
>>
>> struct{ (T(int)) } struct{ T[int] }
>>
>> interface{ (T(int)) } interface{ T[int] }
>>
>> [](T(int)){} []T[int]{}
>>
>> To test this better understanding, and to get a feel for this alternative
>> notation, we will begin to make changes to our prototype implementation
>> such that it accepts either parentheses or square brackets (only one or the
>> other) in a generic Go package. Those changes will first appear as commits
>> to the dev.go2go branch
>> <https://go.googlesource.com/go/+/refs/heads/dev.go2go>, and eventually
>> in the playground <https://go2goplay.golang.org/>.
>>
>> If square brackets don't lead to unforeseen issues, we have another fully
>> explored notation to choose from, which will allow us to make a more
>> informed decision.
>>
>> - gri, iant
>>
>> PS: For ambiguities with angle brackets consider the assignment
>>
>> a, b = w < x, y > (z)
>>
>> Without type information, it is impossible to decide whether the
>> right-hand side of the assignment is a pair of expressions
>>
>> (w < x), (y > (z))
>>
>> or whether it is a generic function invocation that returns two result
>> values
>>
>> (w<x, y>)(z)
>>
>> In Go, type information is not available at compile time. For instance,
>> in this case, any of the identifiers may be declared in another file that
>> has not even been parsed yet.
>>
>>
--
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/73d47647-ea29-49a0-b3f3-e461f5a35c6an%40googlegroups.com.
