Hi all, I just found out that there is a wiki <https://github.com/golang/go/wiki/Go2GenericsFeedback> for this kind of discussion, looks to me like a better venue, more organised, more interest, and just recently proposed on golang.org.
Scott On Sunday, 2 September 2018 10:09:43 UTC+2, Tristan Colgate wrote: > > 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, <rogp...@gmail.com <javascript:>> > 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 >> <javascript:>> 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...@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...@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.
