I really can’t promise to ever fully evaluate all generics proposals. Perfectly understandable. I’ll show the benefits without you needing to fully evaluate the proposal then :)
it’s still unusual in Go for a name that appears in a list to become in scope for the rest of the list and for the following body. Okay, so here is the main benefit of the scoping. Let’s take this simple function that returns a static array with all elements filled with some provided value. Here’s how the signature would look in my proposal: func Filled(gen n, x gen T) [n]T And here’s how it would look if we had to list the generic arguments in a separate list (feel free to supply gen with any other word): func Filled(gen n, T)(x T) [n]T Now, in this latter version, it’s not really clear how and where the generic type gets inferred. Do I need to specify it manually? Under what circumstances? When is the compiler able to infer it for me? Answers to these questions are not clear. On the other hand, in my proposal, the answers are very clear: unnamed arguments get specified, everything else gets inferred. func Filled(gen n, x gen T) [n]T// ^ ^// specified inferred Furthermore, there is never a choice between specifying and inferring a generic type. The signature tells exactly which one the user must do. One more minor benefit of this syntax is that it eliminates any extra parentheses, keeping the clutter down and parsing easy. I’ll respond to one more of your concerns. There is also integer, signed integer, unsigned integer, comparable, ordered, float, complex. One can even think of addable (includes string) and indexable and sliceable. Sure, we can imagine many ways of dividing types into groups. But just because we can imagine that does not mean we need to. I would argue that the “number contract” is far more useful than “addable”, “indexable”, or anything else you can imagine. The “number contract” would include all the number types (int*, uint*, float*, complex*). Arithmetic and logic operations common to these types would be available. This is a rich set of operations: +, -, *, /, <, >, and so on. Also, all of these types allow using untyped integer constants as their values. Sure, you wouldn’t be able to put strings in Sum function with this proposal, but do you really need to do that? I don’t think so. št 6. 6. 2019 o 1:08 Ian Lance Taylor <[email protected]> napísal(a): > On Wed, Jun 5, 2019 at 3:02 PM Michal Strba <[email protected]> wrote: > > > > Ian, have you had the time to evaluate the improvements to my proposal > (the original one in this thread)? I'd love to hear if it has some more > significat shortcomings and know what to think about. Or, if it has no > perspective, I'd love to hear why. > > > > I know you're busy, so responding with "I haven't had the time yet" is > completely understandable. > > I really can't promise to ever fully evaluate all generics proposals. > There are simply too many of them. All I can honestly do is throw out > some quick comments, as I've done already. If you want detailed > feedback, I encourage you to seek it from other people. > > As I said in my reply to Randall earlier " relying on a general > construct like "number" is problematic in Go. There are many > different ways to slice up Go's types. "number" is just one of them. > There is also integer, signed integer, unsigned integer, comparable, > ordered, float, complex. One can even think of addable (includes > string) and indexable and sliceable." > > I'm also still concerned about scoping. You added some text, but it's > still unusual in Go for a name that appears in a list to become in > scope for the rest of the list and for the following body. > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAO6k0us4gdyXcq%2Bu4iXEs_xNhH2GV%2BT5Rtem6ZFXbnf_sRTE6A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
