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 equivalent to your StrNum example in my syntax would be:
contract num int, int8, int16…
contract StrNum {
num
String() string
}
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
func MinInt(a, b int) int {
if a < b {
return a
}
return b
}
Andy
> On Oct 24, 2018, at 9:47 AM, Burak Serdar <bser...@ieee.org> wrote:
>
> 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.
