On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm <andybalh...@gmail.com> 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 <bser...@ieee.org> wrote:
>
> 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.
>
>
--
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.
