Aha, I see what the other set of operators are. While what I thought still
stands: All of these operators should be handled by the compiler, the user
no need to think about them at all - let the compiler retrieves them
implicitly from the function body. In terms of convertible, I think it is
neat to express them in contract.
On Thursday, September 6, 2018 at 5:12:08 PM UTC-7, Axel Wagner wrote:
>
> On Fri, Sep 7, 2018 at 2:00 AM xingtao zhao <zhaox...@gmail.com
> <javascript:>> wrote:
>
>> Try to raise my point here (from another thread):
>>
>> I think all of the operator constraints should be retrieved implicitly.
>> The proposal of the contract on operators seems a design flaw to me: why do
>> we express that if < is in the contract, all other operators are also
>> allowed? I think we do not have to express them in contract. In go, we may
>> add new methods to a type, but we can not change the operator set. This
>> means that there are only few operator sets: arithmetic operators, equality
>> operators, dereference operator, addable(?). I can not figure out other set
>> of operators.
>>
>
> There is also ==nil (which works differently from == itself), the
> arithmetic operators split into multiple classes (floats/complex don't have
> % or <</>>), you have real/imag/complex, make, make2, make3, an unbounded
> number of index(K,V), <-, ->, close, [:], copy, append, dereferencing, an
> unbounded number of convertible(T), assignable(T)…
> I think I've run out.
>
> I'm not saying this is not possible to model with a relatively small set
> of constraints (especially if you're fine ignoring the less important
> ones), but it's not *quite* as simple.
>
> And in go, as we never concern about the operators availability before, I
>> think in generic we could still keep the same and just let the compiler
>> knows these constraints on operators.
>>
>> It is still good to be able to explicitly express type conversion in
>> contract, which is very clear.
>>
>> On Thursday, September 6, 2018 at 4:29:55 PM UTC-7, Axel Wagner wrote:
>>>
>>> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor <ia...@golang.org>
>>> wrote:
>>>
>>>> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>>>> <axel.wa...@googlemail.com> wrote:
>>>> Interesting point. But is there any way to solve it short of
>>>> explicitly listing types? Is there any generics system in any
>>>> language that avoids this problem?
>>>>
>>>
>>> I'm not saying this would be the solution, but since you asked:
>>> Refinement types (implemented e.g. in Liquid Haskell).
>>>
>>> But FWIW, I was using that as an example. There are others, where e.g.
>>> range allows ranging, but has vastly different semantics for string, map,
>>> channel and slice. Or the string(v) example I mentioned, where []rune
>>> passes the contract
>>> contract foo(v T) {
>>> for i, b := range string(v) {
>>> }
>>> }
>>> But if the author was not considering that, might end up with unexpected
>>> results when indexing. Or make(T, N), which is semantically very different
>>> for maps, channels and slices (among other things, for slices,
>>> len(make(T,N)) == N, for the others len(make(T,N)) == 0).
>>>
>>> The other day I had a lengthy conversation with Rog Peppe, David
>>> Crawshaw and Nate Finch on twitter and I'd argue that neither of us would
>>> really count as a Go-novice and we *still* weren't always clear what types
>>> certain contracts allowed and excluded.
>>>
>>> I believe that these cases will become more and more clear, when it
>>> comes to actually write a type-checker, so I don't even really think we
>>> have to talk about all of them or compile a list. I just went away from
>>> having these conversations with the clear impression that contracts are a
>>> non-obvious way to express constraints.
>>>
>>> I think it is clear that we are not going to do that.
>>>>
>>>
>>> But there will be *some* implied capabilities, I assume (and FWIW, the
>>> example I mentioned is IMO pretty similar to ==/!= and </<=/>/>=). For
>>> example, the design explicitly calls out that == will allow using something
>>> as a map-key:
>>>
>>> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
>>> Note, that contract { var _ map[T]bool } would also work and be
>>> explicit. But it already shows that at least *some* implicit constraints
>>> will probably be desirable.
>>>
>>> I understand the arguments in favor of contracts. Personally, I just
>>> tend to think that the disadvantages outweigh them. But that's just, like,
>>> my opinion :) There's still lots of time to see.
>>>
>>> > Of course that doesn't *have* to happen - you could just literally only
>>>> > allow the expressions given in the contract, but then the contract
>>>> > potentially becomes very verbose, as it has to cover lots of ground.
>>>> For
>>>> > example, `a[0]` allows integer-indexing, but it technically only
>>>> allows to
>>>> > pass 0. Extending that to arbitrary integers is what's probably going
>>>> to
>>>> > happen (and an example of an implicit capability) - but then that
>>>> code is
>>>> > less type-safe then it needs to be, as Arrays already provide tight
>>>> bounds
>>>> > for constant-indices. You can say that `a[N]` then allows indexing
>>>> with any
>>>> > constant <= N (to make those bounds explicit), but at that point I
>>>> would
>>>> > criticize that the argument "contracts are just familiar Go syntax"
>>>> becomes
>>>> > less and less convincing, because you are introducing all these
>>>> special
>>>> > semantical meanings to expressions.
>>>>
>>>> Sure, but I didn't introduce them. Go already permits indexing [N]int
>>>> with variables with values larger than N. Go has no way of expressing
>>>> that kind of type constraints. I don't see any reason why we should
>>>> try to express it in a generics implementation.
>>>>
>>>> Ian
>>>>
>>> --
>> 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...@googlegroups.com <javascript:>.
>> 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.
