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. 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/AC62F9E3-DC79-40B7-85C1-D6CB5CA0838A%40gmail.com. For more options, visit https://groups.google.com/d/optout.
