mark pointer methods on interface type definitiion, not function?

[Randall O'Reilly]

Would it make sense to mark the methods requiring pointer receiver types on the interface definition, instead of on the function type parameters? It seems more logical given that this should be a general property of the semantics of the interface method in question, and not something each function should have to deal with separately.

From the example in the draft proposal:

// Setter is a type constraint that requires that the type
// implement a Set method that sets the value from a string.
// Further, the Set method must take a pointer receiver.
type Setter interface {
*Set(string)
}

The * marks this method as requiring a pointer receiver. This constraint can thus be enforced generically for any type up front at constraint-checking time.

A function using this interface constraint would just have a regular non-pointer type:

func FromStrings(type T Setter)(s []string) []T { ... }

- Randy

[Anderson Queiroz]

I see your point, but the interfaces do not deal with the implementation details, they only specify a behaviour. In your proposal the interface definition would constrain how it can be implemented. Whoever is implementing the interface is responsible for the constraints related to the implementation, not the interface definition.