from Hacker News

Go's updated generic proposal (Contracts)

by simonz05 on 7/27/19, 8:45 AM with 61 comments

  • by tapirl on 7/28/19, 8:59 AM

    It is not a proposal, it is a draft.

    The new draft improves the contract part. But generic declaration part still looks some verbose. There are many repetitiveness, such as the Map example: https://github.com/golang/proposal/blob/4a54a00950b56dd00964...

        func New(type K, V)(compare func(K, K) int) *Map(K, V)
    func (m *Map(K, V)) Insert(key K, val V) bool
    func (m *Map(K, V)) find(key K) **node(K, V)
    func (m *Map(K, V)) Insert(key K, val V) bool
    func (m *Map(K, V)) Find(key K) (V, bool)
    func (m *Map(K, V)) InOrder() *Iterator(K, V)
    And I didn't find how to write a contract which requires a type must have some specified fields in this draft.

  • by latchkey on 7/28/19, 8:31 AM

    I've been doing some work in Dart/Flutter recently and I'm finding it to be a nice mix of Java/JavaScript/TypeScript/Golang. It has generics which work pretty well, although I've already found a very small bug in it [1].

    Initial reading of this document makes me feel it is really over complicated compared with Dart.

    [1] https://github.com/dart-lang/sdk/issues/37626

  • by steinuil on 7/28/19, 9:25 AM

    I don't understand what's the difference between single-parameter contracts and interfaces. Aren't contracts only useful when there's two or more type parameters involved?

    Edit: didn't read through the whole thing, I guess contracts can do things that interfaces don't. I think the overlap still makes things a bit awkward though.

  • by tomohawk on 7/27/19, 9:49 AM

    Excellent example of clear and concise writing, introducing a subject.

  • by baby on 7/28/19, 9:05 AM

    I wish there was a way to have generics without:

    * letting people being able to abuse them. C++ cough cough.

    * making it clear to people reading the code what is happening.

    I’ve noticed a few things:

    * associated types in Rust are much clearer than generics

    * one letter generics are “overly generic” and do not describe enough.

    * the declaration of the type really adds verbosity

    So what can a language do?

    1. Maybe change the syntax to this one:

      func eat(food []generic.Type)
    Or

      func eat(food []g::type)
    Or something that doesn’t involve adding more <> or ()

    2. Forbid one letter generic or force a description of the generic or even better: force listing all the types that are currently using this generic NEXT to the generic!

      g.type -> {egg, bacon}
  func eat(food []g.type)
    But then you can’t use a generic from another package... but maybe it’s a good limitation?

    Or force a generic to have a description, which is what golang is doing with interfaces. The problem is that we can’t combine difference interfaces like in Rust/ocaml

  • by threeseed on 7/28/19, 9:17 AM

    It is just me or do contracts look a lot like type classes.

  • by simonz05 on 7/27/19, 8:50 AM

    There is some more information in this liveblog from Ian's talk, Generics in Go [1], and the *.go2 files in Robert Griesemer's change list [2]

    [1]: https://about.sourcegraph.com/go/gophercon-2019-generics-in-... [2]: https://go-review.googlesource.com/c/go/+/187317/

  • by MrBuddyCasino on 7/28/19, 10:22 AM

    I don’t quite get what contracts are needed for? This

        func Print(type T)(s []T)
    could be written as

        func Print(type T implements SomeInterface)(s []T)
    What am I missing?

  • by grenoire on 7/28/19, 8:07 AM

    Honestly it just reminds me of Rust's traits (granted I didn't read the entite spec.), could this come with operator overloading too?

  • by misrab on 7/28/19, 9:47 AM

    If what Generics fundamentally solve is having to type out an almost identical function for many types, why not just have macros?

  • by johnisgood on 7/28/19, 12:25 PM

    For a second I thought it was related to {pre,post}-conditions.

  • by antpls on 7/28/19, 8:55 AM

    I have knowledge in Python and never developed in Go, so I can't comment the Design choices. On the form, in my humble opinion, the PEP style is easier to read : presenting rational and constraints before the proposed solution.

    It would mean moving (and a bit of rewording) "Discarded ideas", "Comparison with Java", "Comparison with C++" before "Design" and after "Background".

    As a reader, I prefer to be presented with the problem first (with the constraints and previously explored ideas), then be presented the logical, "obvious", proposed solution.