On Wed, Jun 5, 2019 at 10:31 PM Randall O'Reilly <rcoreil...@gmail.com> wrote: > > On Jun 5, 2019, at 8:36 PM, Burak Serdar <bser...@ieee.org> wrote: > > > > On Wed, Jun 5, 2019 at 11:47 AM Randall O'Reilly <rcoreil...@gmail.com> > > wrote: > >> > >> It’s great to see that so many people share my considerable enthusiasm for > >> this proposal! Seriously, nobody is willing to take a look and provide > >> any feedback? > > > > This reminds me of a proposal I wrote some months ago that uses > > existing types as contracts with a new "like" keyword for primitives. > > Your proposal takes that idea further and gets rid of contracts > > completely. Even though the syntax is cleaner, I think you lost some > > of the expressive power of contracts. For instance: > > > > Edges []Edge : does this mean that Edges is an array where each > > element is a type that satisfies Edge (and thus each element can have > > a different type), or that it is an array where each element is the > > same concrete type of Edge? > > > > The motivation behind contracts was to ensure generic types can be > > compiled before instantiation. This proposal seems to give up on that. > > Just to be clear, the proposal is definitely NOT to get rid of contracts at > all! The point is actually very similar to your proposal (as you noted) — > here’s the link for reference: > https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3 > > Specifically any contract specified using like(), e.g., your SignedNumber > example (which becomes simply `signed` as the builtin generic type in my > proposal) should be essentially identical from the compiler’s perspective, > right? They specify the same exact contract, just using a different syntax. > > Likewise, any use of a generic native “slice” or “map” type definitely > specifies a very concrete “contract” — it is just not an *arbitrary* contract > — it is just the familiar existing contract that we all know and love.. > > I’m not sure about the claim that some of the examples in your proposal could > actually be compiled effectively in advance of instantiation. For example, > anything involving a struct with specific fields (which is achieved using the > struct interface syntax in my proposal, but is essentially functionally the > same as the corresponding structs in your proposal and the draft proposal, > again just with a different simpler syntax that avoids explicit type > parameters), would presumably benefit considerably by knowing the concrete > types involved to know about field offsets and specific types used in > operations etc. If you don’t know the concrete type(s), then you’re stuck > using virtualized “boxing” kinds of approaches for everything in the code, > right? If you wait until you have the concrete type, the compiler can decide > the best way to optimize the various costs associated with boxing vs. code > bloat etc.
You don't need boxing with contracts specified as a list of possible types. If you have a contract that lists types T1, T2, ... as possible types, then you can compile the types and functions using that contract once for each minimal concrete type that implements T1, T2,.... A minimal concrete type that implements T1, T2,.. can be obtained from the contract definition by creating a struct/interface containing the list of fields/methods contract type has. > > Anyway, just to reiterate, the core idea is definitely *not* to abandon > contracts — just to use existing native contracts, which constitute a > well-known, well-tested finite “basis set” of contracts. By using this very > limited space of contracts, we can use builtin keywords and a much simpler > syntax, and the compiler should actually have an *easier* time compiling > generic code compared to supporting arbitrary contracts. I think it really > is the same basic idea from your like() proposal, so I “like” it :) > > - Randy > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2RqqDs1qu%3Dxgkupr-LVP-_DA8VHZvs4g%3DLKAr1S85sh7btQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
