Just read: https://emilymaier.net/words/getting-specific-about-generics/
I think I concur, keep specification of behaviour in interfaces if possible. Contracts overlap too much. If interfaces can do the job, all be it less elegantly, the extra verbosity seems worth it to avoid the feature overlap. What I'm mostly worried about is a future where new comers have to learn two overlapping features. Inevitably people won't stop using interfaces. Contracts are too expensive, cognitively, if they aren't going to become pervasive, but that seems to throw out interfaces (even if they can be made to cooperate). On Sat, 1 Sep 2018, 21:55 roger peppe, <rogpe...@gmail.com> wrote: > FWIW I've published some ideas about how contracts and interface types > could be partially unified, and contracts significantly simplified, > which I think is quite pertinent to the above discussion. > > Doc here: > > https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69 > > > > On 1 September 2018 at 20:15, Scott Cotton <w...@iri-labs.com> wrote: > > > > > > On Saturday, 1 September 2018 20:29:31 UTC+2, Axel Wagner wrote: > >> > >> I don't understand what you are trying to say. You assert that there > >> wouldn't be a type-error, but you don't actually justify that. > > > > > > There are 2 examples, both are (to me) intuitive suggestions and not the > > result of a phd thesis worth of research :) continued below. > > > > > > > >> It seems pretty obvious to me, that if you instantiate my MultiReader > >> example to, say, *strings.Reader, it would fail to compile. Because > >> *multiReader is not a *strings.Reader (and you'd have to replace R with > >> *strings.Reader everywhere in the signature, that is the exact reason we > >> want generics to begin with). > > > > > > That's why I didn't use R for another, distinct Reader. For the > signature > > of your MultiReader example I changed the return type from "R" (the type > > argument) to "Reader" (the name of the contract). In a hand-wavy formal > > way, the return type would serve as a new type argument to Reader, > > independent of R. Put in an intuitive (to me) way: Since MultiReader > > returns something which presumably conforms to the contract Reader, why > not > > just say that instead of the type argument R? > > > > > >> > >> The example you give for "unifying this" isn't actually syntactically > >> correct, AFAICT. At least I can't find anything in the design that would > >> allow using the identifier of the contract in its arguments - and it's > >> unclear to me what that would mean. > > > > > > Apologies, I'm responding to the proposal, just giving my 2 cents. I am > not > > asserting that the examples I give are syntactically correct according to > > the proposal. I am suggesting that the concepts of "contract" and > > "interface", can (probably) be defined for Go > > in a unified way. I am not supposing the definitions in the proposal of > > "interface" and "contract" in suggesting this; to the contrary I am > > suggesting these concepts are what Go would define them to be and hence > are > > flexible and not yet fixed. I do not think saying interfaces and > contracts > > are different because the proposal or other background such as Haskell or > > type theory treat them differently is a convincing counterargument to my > > suggestion of exploring the unification of contract and interface. > > > >> > >> > >> To provide another way to clarify that interfaces and contracts are > >> different: > > > > > > This again assumes a priori interfaces and contracts are different. I am > > trying to suggest to drop this assumption and see what happens. To me, > it > > seems, so far, good things would happen. > > > >> > >> * How would you build fmt.Println using contracts? > >> > >> * One of the main motivators behind adding generics is the lack of > >> type-safety for containers (say, container/list). While all methods > mention > >> the same type, interface{}, it is not checked for consistency between > >> invocations. This is a bug for type-safe containers, but it's a feature > for > >> fmt.Println. > > > > > > So perhaps containers could use a contract which does not instantiate > each > > type argument distinctly, forcing uniformity of types and > > more or less like in the proposal. And perhaps situations desiring > > heterogenous types, such as fmt,*f(), could use a different kind of > > contract which instantiates each type argument independently at the call > > site. To distinguish them, some syntax could be proposed such as > > > > contract Reader(r Reader.(*)) { ... } > > vs > > contract Reader(r Reader) {...} > > > > I am far from the genius who is capable of thinking this idea through and > > making it as solid as the proposal overnight. Just expressing the > opinion > > that unifying the concepts of contract and interface seems to me like a > good > > idea to explore, and that a priori assuming they are different doesn't > help > > advance exploring it. > > > > Scott > > > > > > > > > > > > > > -- > > 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. > > -- > 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. > -- 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.
