You're right, I apologize. It not only wasn't nice, it also was an ineffective way to make my point. So let me try to make that point as clearly as I can.
You and many others have tried to replace contracts with interfaces. But if generics are to have operator constraints like T == T, then something in the language has to change. Either not all interfaces are types, or some interfaces have methods that can't be called, or Go operators can have operands of different types. These changes are not minor tweaks: they alter fundamental aspects of the language. Contracts, on the other hand, are purely additive. They only come into play when writing generic code. If I'm not mistaken, the draft design doesn't change or even add anything to non-generic Go. There is something attractive about that orthogonality. Maybe there is a way to use interfaces in place of contracts, and I hope people keep trying, because the attraction is obvious. But in the all the suggestions I've seen so far, the cure is worse than the disease. (or, allow embedding interfaces into contract-declarations, remove the > "type-checking function body" idea and instead define a set of > base-contracts you can use for operators) and you'd end up with pretty much > my design. > That doesn't sound like your original design at all. Your original design tries to replace contracts with interfaces. In this suggestion, contracts are there, but (1) you can write an interface directly in the contract body, and (2) the body is much more restricted. The first seems problematic, because for multi-parameter contracts you wouldn't know which type the parameter referred to. The second seems reasonable to me. Now we can talk about issues like whether this adds too many names to the language, or whether you've described all the important constraints (I think conversion and assignability are important, for instance). On Sunday, September 9, 2018 at 5:21:28 PM UTC-4, Axel Wagner wrote: > > I don't think saying that is is productive. contracts are more than just > "identifiers used as constraints", they are also a syntactic construct to > specify those. I specifically don't allow that and that's the whole point > I'm making. So this doesn't seem like a particularly nice way to have a > discussion. > > But yes, if it makes you happier, we can call them "contracts", allow to > embed them into interfaces and remove contract declarations from the design > (or, allow embedding interfaces into contract-declarations, remove the > "type-checking function body" idea and instead define a set of > base-contracts you can use for operators) and you'd end up with pretty much > my design. > > On Sun, Sep 9, 2018 at 11:17 PM Jonathan Amsterdam <jbams...@gmail.com > <javascript:>> wrote: > >> >> >> On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote: >>> >>> On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam <jbams...@gmail.com> >>> wrote: >>> >>>> The problem is that this program seems to type-check, but it is >>>> invalid. The == operator is specified to work on operands of the same >>>> type, >>>> and it is being used on operands of different types. >>>> >>> >>> Good point. I have to think about it. An ad-hoc solution, FWIW, would be >>> to only take into account (or allow) pseudo-interfaces for type-constraints. >>> >> >> The draft design has a name for those: contracts. >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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.
