Quoting Ian Lance Taylor (2018-10-16 16:02:57) > On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond <e...@thyrsus.com> wrote: > > > > New rule: A function on variables of undefined formal-argument types > > compiles to a template (not a textual template - we don't want identifier > > capture). At each callsite of the function, the undefined types in the > > formals are bound to the types of the arguments in the call. If every > > operation in the resulting code is defined, the code compiles as if the > > generic function had been written with the actual argument types at the > > callsite. If not, the compiler throws an error on each undefined operation.
What is this intended to buy us? Is this as Ian T suggests in lieu of any kind of contract system? Or is it just to reduce verbosity in type declarations? Or both? If it's the former I agree with Ian T's complaint that this makes the contract brittle. If it's the latter, we could just say that undefined formals have no constraints, and so any use of them that depends on something that not all types support is an error. I'm still not in love with this, as I expect obscure error messages when someone makes a typo, or accidentally being generic when you didn't mean to. I outlined a similar thing in another thread, where you use a lexical convention to distinguish type variables from concrete types, so you don't need an explicit parameter list. But this was in the context of someone having suggested just not supporting bounded type parameters at all, so the question of where you write the bounds didn't come up (and I still think bounds are important). I also still think we should just use interfaces; elsewhere in this thread I linked to my proposal about this, which when you add operator overloading using Eric's solution to the `==` semantics problem covers every concrete issue I've seen raised so far. -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. For more options, visit https://groups.google.com/d/optout.
