This text seems somewhat contradictory:
The function Init cannot be instantiated with the type MyInt, as that type
> does not have a method Set; only *MyInt has Set.
>
...
>
If a method is listed in a contract with a plain T rather than *T, then it
> may be either a pointer method or a value
For those who haven't already noticed, I thought I'd point out that the
draft design has now been changed (as Ian intimated it might be) so that
contracts may now require a pointer method in some cases i.e. if the type
parameter is T one can now specify that *T has a certain method.
In
On Thu, Aug 1, 2019 at 6:35 AM, Max wrote:
> 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?
>
Yes, this is something which is supported be
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) {
Ah, thanks, I think I understand now. AIUI this would essentially require
that the author of a generic function or type would have to write a
contract to specifically allow or disallow pointer/value receivers to
satisfy the contract?
I personally don't really like the idea of putting that
Why make any distinction between pointers and non pointers? Isn't the
(usual) point to allow the caller to decide upon instantiation?
We define a contract in terms of an unknown set of types and then let
whoever uses it fullfil the contract however they want?
On Tue, Jul 30, 2019, 21:57 wrote:
On Tuesday, July 30, 2019 at 7:47:05 PM UTC+1, Axel Wagner wrote:
>
> On Tue, Jul 30, 2019 at 8:31 PM > wrote:
>
>> My suggestion was that you can't use a pointer type as a type parameter
>> if the latter is subject to a contract.
>>
>
> I'm not sure I understand you. Wouldn't that preclude
On Tue, Jul 30, 2019 at 8:31 PM wrote:
> My suggestion was that you can't use a pointer type as a type parameter if
> the latter is subject to a contract.
>
I'm not sure I understand you. Wouldn't that preclude using a generic map
with pointers as keys?
> In the case you mention, the contract
My suggestion was that you can't use a pointer type as a type parameter if
the latter is subject to a contract.
In the case you mention, the contract could be expressed as a disjunction
of value and pointer methods:
contract stringer(T) {
T String() string, *T String() string
}
However, if
On Tue, 30 Jul 2019 at 14:58, wrote:
> One way of avoiding this muddle between pointer and value methods would be
> to require that any type parameter (T say) which is subject to a contract
> cannot be replaced by a pointer type.
>
What do you mean by this? Do you mean you can't use a pointer
One way of avoiding this muddle between pointer and value methods would be
to require that any type parameter (T say) which is subject to a contract
cannot be replaced by a pointer type.
The contract could then be absolutely explicit about whether a method's
receiver were T or *T and any
11 matches
Mail list logo
