On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher <ge...@speicher.org> 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. ;)
This seems similar to the discussion at
https://groups.google.com/d/msg/golang-nuts/mXn9x01mFzM/Zf7lSXVuBgAJ .
It seems hard to know how to instantiate a generic function or type,
as there is no clear information in the declaration as to the presence
or order of the type parameters.
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/CAOyqgcV%2B%2BdQu%3DXo4G5owBFbYddRN1hSmwyr4LsF9mJOfVsFaiw%40mail.gmail.com.
