I also felt uneasiness with the definition of contracts but couldn't put my finger on the reason. Merovious made now clear to me that the language to define contracts is the problem.
Nevertheless, I do think we need to keep contracts because they are a superset of interfaces. Interfaces specify only a collection of methods, and contracts specify a collection of methods and operations (e.g. ==). Remember that base types can also have methods. We may also want to restrict types to referenced, or unreferenced, because it determines if an assignment make a copy or not.
Contracts are types of generic parameters. I would find more natural to define these generic parameter types like this
type foo generic { ... }
As suggested by Merovius, the content would be a list of method signatures, operations, interface names or predefined operation set names.
Isn't a major part of the idea in the article that we can replace the "and operations" part with a system of pseudo-interfaces that encompass those basic operations?
Nevertheless, I do think we need to keep contracts because they are a superset of interfaces. Interfaces specify only a collection of methods, and contracts specify a collection of methods and operations (e.g. ==). Remember that base types can also have methods. We may also want to restrict types to referenced, or unreferenced, because it determines if an assignment make a copy or not.
Contracts are types of generic parameters. I would find more natural to define these generic parameter types like this
As suggested by Merovius, the content would be a list of method signatures, operations, interface names or predefined operation set names.