I think that a single syntax allowing both pointer receivers and value
receivers - with no mechanism to distinguish them - creates unnecessary
ambiguity, and in some cases it can concretely be a problem.
Consider the following example, adapted from 'math/big.Int`:
```
contract Comparable(T) {
// return -1 if receiver is lesser than 'other'
// return +1 if receiver is greater than 'other'
// return 0 if they are equal
T Cmp(other T) int
}
```
it seems perfectly reasonable yet, depending on the exact semantics of
contracts, `math/big.Int` may have troubles satisfying it, because its
method 'Cmp' has the signature
```
func (recv *big.Int) Cmp(other *big.Int) int
```
Thus it would require 'T' to be a pointer - namely '*big.Int' - to match.
It would mean that the receiver itself of the contract 'T Cmp(other T) int'
is a pointer. Is it a case allowed by contracts?
And how does it interact with the rule that both pointer receivers and
value receivers are allowed?
If you ignore for a moment the ability of contracts to specify a union of
types,
I prefer my proposal https://github.com/cosmos72/gomacro#generics where
contracts are just generic interfaces,
and they can *optionally* specify the receiver type - used in case you want
to *remove* the ambiguity between pointer and value receiver types.
They clearly require the possibility to specify multiple contracts in a
generic type or function signature, while the current proposal
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#methods
allows only a single contract in a in a generic type or function signature,
thus requiring contracts to be able to specify the methods of several
unrelated types.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/cf04c27c-6ac0-4b64-96b4-f0e7a1a2a99d%40googlegroups.com.
