Two thoughts about the contracts proposal:
- In the proposal a contract is loosely defined as the resulting
implications from a function. In the interests of starting a discussion, it
seems like a great starting place. However, it feels like it would be
useful to spell it out in the draft proposal. Otherwise, discussions about
whether a contract syntax is the best form are difficult to assess.
- Since the contract is loosely defined as following the syntax of a
function, that leaves open the opportunity for contracts that specify the
same thing to be written in radically different ways. Go's strength stems
in part from the clarity of purpose for the code written in Go.
What's defined in a contract, made explicit - is this an exhaustive list?
- Which operators work on an instance of a type (==, <, >, ++, --)?
- What can an instance of the type be cast to?
- What is the base type of the type? (int, float, int64, string,
struct{}, [], map[], interface{}...).
- What method signatures can be found on an instance of a type?
- What members and their types can be found in instances of structure
types?
Does that capture it?
Clarified this way, it seems clear that generics support could be added to
the language over time, instead of in one gigantic change. For example,
what if the generics implementation, in its first manifestation, didn't
support all the operators? That capability could be added in the future,
without breaking backward compatibility. Or, in the first iteration,
perhaps "range" could only be used on generic slices, instead of also
including maps?
As to the imprecise syntax of the contract, the more I think about it, the
more I think I want an explicit contract syntax, instead of a mock function
syntax. The mock syntax approach means that different portions of the Go
community could develop different "idioms" for specifying the same thing,
which runs in the opposite direction of how the Go team has traditionally
defined the language.
Having said all that, I'm pleased to see the thought that has gone into the
proposal. Thanks so much for all the hard work.
Eric.
--
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.
