On Wed, Oct 24, 2018 at 3:52 PM Andy Balholm <[email protected]> wrote:
>
> What I’m doing with structural contracts is basically the same as what you’re
> doing with struct and interface types as contracts, except that (I hope) the
> syntax is a little clearer.
>
> I added the support for operators basically to avoid having the supportsEqual
> contract as a special case that needs to be built in. Most other operators
> could be handled just as well with an enumerated contract, so maybe it would
> be better to just have supportsEqual or comparable as a built-in contract.
The only problem with that, I think, is that the contract syntax is no
longer a struct or interface. I see your point though.
> I was envisioning the type switches being evaluated at compile time if the
> compiler was producing a type-specialized version of the generic function.
> Min(int) would probably produce exactly the same machine code as
That's a neat idea.
>
> func MinInt(a, b int) int {
> if a < b {
> return a
> }
> return b
> }
>
> Andy
>
> > On Oct 24, 2018, at 9:47 AM, Burak Serdar <[email protected]> wrote:
> >
> > On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm <[email protected]> wrote:
> >>
> >> Here’s my attempt at streamlining it, as well as adding a way to deal with
> >> the operator/method dichotomy:
> >> https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2
> >
> > Thanks!
> >
> > However, I think yours is a somewhat different approach altogether.
> > The main idea I have is that existing types should be used as
> > contracts. That means no operators in contracts.
> >
> > Also: when you list types in a contract:
> >
> > contract X {
> > T1
> > T2
> > }
> >
> > I defined it to mean that any type satisfying X must satisfy both T1 and T2.
> >
> > And with "like" type contract specifications (enumerated contracts)
> >
> > contract X like(int,int8,int16...)
> >
> > A type satisfying X is a derivative of any one of the types listed. So
> > it is possible to write:
> >
> > contract StrNum {
> > like(int, int8, int16,...)
> > interface {
> > String() string
> > }
> > }
> >
> > meaning StrNum must be an integer that implements String()
> >
> > The "type switch" for contracts imply that contracts are a runtime
> > construct. In my case, contracts are purely compile time.
> >
> >
> >>
> >> Andy
> >>
> >> On Oct 23, 2018, at 9:37 AM, Burak Serdar <[email protected]> wrote:
> >>
> >> On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar <[email protected]> wrote:
> >>
> >>
> >> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich <[email protected]> wrote:
> >>
> >>
> >> * Burak Serdar <[email protected]> [181018 15:08]:
> >>
> >> tbh, I am not trying to avoid operator overloading, I am trying to
> >> avoid the contracts. With operator overloading, you can write:
> >>
> >> func F(a,b type T like(int,X)) {
> >> if a<b {
> >> ...
> >> }
> >> }
> >>
> >> provided X is a type that supports <.
> >>
> >>
> >> Are you trying to avoid the concept of contracts or the specific syntax
> >> proposed in the design draft?
> >>
> >>
> >>
> >> My intent was to use existing types as contracts instead of an
> >> abstract contract specification. In this scenario, a contract is a
> >> more abstract concept that an interface. Above, type T like(int,X)
> >> would mean:
> >> - func F compiles for T=int and T=X
> >> - F can be instantiated for any type derived from int or X
> >> So instead of specifying the precise type semantics required by F,
> >> you'd approximate the intent and declare that F would work for types
> >> that look like int, and X.
> >>
> >> When you apply the same idea to structs:
> >>
> >> type T like struct {a, b, int}
> >>
> >> would mean that T can be substituted by any struct containing two int
> >> fields called a and b.
> >>
> >> This idea ran into problems later on: I cannot explain simple
> >> contracts such as "type T must support ==".
> >>
> >>
> >>
> >> I typed this up in a more organized way, and it turned out to be an
> >> alternative declaration for contracts without touching the generics
> >> parts of the proposal.
> >>
> >> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
> >>
> >> --
> >> 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 [email protected].
> >> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
