On Wed, Sep 12, 2018 at 3:55 PM Tristan Colgate <tcolg...@gmail.com> wrote:
> I'll leave the grown up to discuss after this I promise) > Don't worry. I'm not grown up by any measure. > I guess if I were going to critique this I would say that optimising for > ease of compiler implementation may not be the best thing. > I tend to agree. And I wouldn't optimize for it, if I wouldn't *also* be of the opinion that it's simultaneously optimizing for ease of use. My criticism of the contracts design is motivated by the user-perspective. And it just so happens, that what I perceive as a fix also ends up making the implementation easier. But I also don't think these two are actually in any way contradictory. The simpler algorithm is not only easier to implement, it's also easier to understand, debug and understand the failure modes of. In the same way as eliminating SAT search from Go modules doesn't only serve the implementer, but also serves the user, because things run faster, failures are simpler to understand and error messages are better - in the same way, I perceive a simple interface-based constraint checker to be user-friendly. Having a package of pre-defined contracts, and a tool and that can produce, > and reduce contracts, if possible, would simplify things. > But that's kind of the crux. If that's needed or how they are usually used - then a) why even have a way to have user-specified contracts and b) doesn't that negate the argument of "not wanting to add a bunch of new identifiers people need to learn"? > To be completely honest, I think I'd be happy with your design if it just > stopped before "Getting rid o boilerplate", I'd rather just live with the > boilerplate than introduce the taxonomy that comes after. > That's why I split it :) > It could, but this would change how people currently understand interfaces > to work, e.g. in regard to nil-ness of interface values. > No, it wouldn't. I don't understand what you mean by that, what I described is purely an optimization, not a semantic change :) That's just as with the contracts design. Both designs make no semantic prescriptions about what implementations are possible and leave that totally up as an optimization to the compiler. As said above excellently by Jimmy Frasche: The idea is to use interface types to specify constraints, not interface values to pass generic values. In func Foo(type T SomeInterface) (v T) v is still semantically of the type specified at instantiation time, not just a SomeInterface value. But, as I said above, I agree that there is need to polish the phrasing here. If I would put this forth as an actual contending proposal, I probably *would* end up adding a separate declaration (say "constraint") too, which works similar to interface-declarations, can embed constraints, interfaces or "pre-declared constraints" (the "pseudo-interfaces") and I would allow using interfaces as constraints, instead of having to wrap them separately - as a convenience. I don't know. We'll see :) -- 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.
