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
<https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2>
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.
