On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar <bser...@ieee.org> wrote:
>
> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich <m...@renich.org> wrote:
> >
> > * Burak Serdar <bser...@ieee.org> [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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
