I don't understand what you are trying to say. You assert that there
wouldn't be a type-error, but you don't actually justify that. It seems
pretty obvious to me, that if you instantiate my MultiReader example to,
say, *strings.Reader, it would fail to compile. Because *multiReader is not
a *strings.Reader (and you'd have to replace R with *strings.Reader
*everywhere* in the signature, that is the exact reason we want generics to
begin with). The example you give for "unifying this" isn't actually
syntactically correct, AFAICT. At least I can't find anything in the design
that would allow using the identifier of the contract in its arguments -
and it's unclear to me what that would mean.
To provide another way to clarify that interfaces and contracts are
different:
* How would you build fmt.Println using contracts?
* One of the main motivators behind adding generics is the lack of
type-safety for containers (say, container/list). While all methods mention
the same type, interface{}, it is not checked for consistency between
invocations. This is a bug for type-safe containers, but it's a feature for
fmt.Println.
--
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.
