On Fri, Sep 7, 2018 at 2:00 AM xingtao zhao <zhaoxing...@gmail.com> 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+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.
