In the draft design paper it says:
"There are a few aspects to a method call that can not be shown in a simple
assignment statement like the ones shown above.
There is no way to specify that a method does not return any values.
There is no way to specify that a method takes variadic arguments.
There is no way to distinguish a method call from a call of a struct
field with function type.
When a contract needs to describe one of these cases, it can use a type
conversion to an interface type. The interface type permits the method to
be precisely described. If the conversion to the interface type passes the
type checker, then the type argument must have a method of that exact type."
I don't know whether anyone has suggested this before but why not disallow
direct method calls on a contract's type arguments altogether and force
people to use interfaces instead?
If there were no suitable pre-existing interface, one could simply nest an
anonymous interface within the contract itself and use that for the
conversion.
The advantages would be:
1. It would always be clear to someone reading the contract what the
method's precise signature was.
2. A contract writer wouldn't need to think up an arbitrary expression or
statement to describe a method's signature (sometimes imperfectly). There'd
only be one way to do it which he/she would already know about.
3. The compiler wouldn't need to make any inferences from the way a method
was used what it's signature was.
The disadvantages would be:
1. It would be slightly more verbose to wrap the allowable methods in an
interface.
2. The compiler would need to check that there were no direct method
invocations on the type parameters within the contract body and flag an
error if there was.
IMO the advantages easily outweigh the disadvantages.
What has become the "hello world" of generic contract programming would now
become:
contract Graph(n Node, e Edge) {
interface {
Edges() []Edge
}(n)
interface() {
Nodes() (Node, Node)
}(e)
}
Now it's true that you'd still not be able to distinguish a pointer method
from a value method using this approach. However, this probably wouldn't
matter in the majority of cases and, if it did, then you could use a
similar trick to that used in the draft to specify a value method.
--
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.
