Presumably the instantiation of generic types and functions will be a lot
more common than the declarations. How does your proposal handle those?
(FWIW, I'm fine with square brackets, or really anything other than parens.)
On Monday, July 20, 2020 at 12:42:13 PM UTC-4 Geoff Speicher wrote:
> This is great work but compared to the rest of Go's existing syntax, I
> personally find it much harder to grok the generic code examples regardless
> of bracket choice.
>
> It seems like a lot of complication stems from what effectively amounts to
> requiring the programmer to declare a new generic type everyplace one is
> needed. This seems like a lot of unnecessary noise, especially when you
> consider that a package is likely to reuse generic types.
>
> What if we were to require (or at least allow/encourage) declaration of
> any generic types at the package level? Then any function or type is itself
> generic by virtue of whether or not it uses any generic types.
>
> So instead of:
>
> // existing proposal requires additional (type T)
> // syntax for type parameter declaration
> func Print(type T)(s []T) {
> for _, v := range s {
> fmt.Println(v)
> }
> }
>
> We would have:
>
> // declare a new package-level type, similar to "type T" but using
> // a new keyword to indicate that it is generic
> generic T
>
> // Print is a generic function because T is a generic type
> func Print(s []T) {
> for _, v := range s {
> fmt.Println(v)
> }
> }
>
> The keyword generic indicates a generic type declaration, and since the
> Print function uses the generic type T, we know that Print is a generic
> function. We don't need any additional syntax at the site of the function
> definition. Type constraints can appear within the type declaration just as
> they do in the existing proposal's "inline" generic declaration.
>
> By encouraging reuse of the generic declaration, this approach also
> encourages better choice of generic type naming instead of the ubiquitous
> T which is used almost exclusively for its brevity in inline generic type
> parameter declarations. For example:
>
> // declare a generic type with constraint of Stringer.
> // the name "Stringable" conveys more meaning than "T".
> generic Stringable Stringer
>
> // type definition requires no extra syntax for a generic type
> parameter
> type StringableVector []Stringable
>
> // method definition requires no extra syntax for a generic type
> parameter
> func (s StringableVector) String() string {
> var sb strings.Builder
> for i, v := range s {
> if i > 0 {
> sb.WriteString(", ")
> }
> // It's OK to call v.String here because v is of
> generic type Stringable
> // and Stringable's constraint is Stringer.
> sb.WriteString(v.String())
> }
> return sb.String()
> }
>
> I don't know how this affects your implementation, but it certainly
> reduces the need for many parser changes, and eliminates the need for extra
> brackets in favor of a new keyword. It's also much easier for my aging eyes
> to read. ;)
>
> Geoff
>
>
--
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/7ad301de-fe8d-4b8c-886f-7d86f8fec4d2n%40googlegroups.com.
