mirror of
https://github.com/golang/go
synced 2024-11-23 00:20:12 -07:00
doc: add FAQ entry about covariant result types
Change-Id: If22b8f358e78deca31bd0b1a25e7966987853405 Reviewed-on: https://go-review.googlesource.com/17083 Reviewed-by: Rob Pike <r@golang.org>
This commit is contained in:
parent
624d798a41
commit
85dcc34e0d
@ -860,6 +860,36 @@ value to hold the error and a type switch to discriminate cases. The
|
||||
syntax tree example is also doable, although not as elegantly.
|
||||
</p>
|
||||
|
||||
<h3 id="covariant_types">
|
||||
Why does Go not have covariant result types?</h3>
|
||||
|
||||
<p>
|
||||
Covariant result types would mean that an interface like
|
||||
|
||||
<pre>
|
||||
type Copyable interface {
|
||||
Copy() interface{}
|
||||
}
|
||||
</pre>
|
||||
|
||||
would be satisfied by the method
|
||||
|
||||
<pre>
|
||||
func (v Value) Copy() Value
|
||||
</pre>
|
||||
|
||||
because <code>Value</code> implements the empty interface.
|
||||
In Go method types must match exactly, so <code>Value</code> does not
|
||||
implement <code>Copyable</code>.
|
||||
Go separates the notion of what a
|
||||
type does—its methods—from the type's implementation.
|
||||
If two methods return different types, they are not doing the same thing.
|
||||
Programmers who want covariant result types are often trying to
|
||||
express a type heirarchy through interfaces.
|
||||
In Go it's more natural to have a clean separation between interface
|
||||
and implementation.
|
||||
</p>
|
||||
|
||||
<h2 id="values">Values</h2>
|
||||
|
||||
<h3 id="conversions">
|
||||
|
Loading…
Reference in New Issue
Block a user