Quoting Eric Raymond (2018-10-16 16:14:46)
> It's up to the programmer to implement things like commutativity.� I
> don't think the language should pre-specify whether < is a partial or
> total ordering.� Any choice of this kind the language makes will
> inevitably turn out wrong a significant percentage of the time.� For
> proper orthogonality we should not specify as much as we can about each
> operator, but as *little* as we can and still have readable code.
> I would say the contract for < is just "takes operands of the same
> unspecified type; returns a bool".
> The fact that this will usually be used to express an order for sorting,
> and that it is anticommutative, is none of the compiler's business.
> It's a convention that libraries will observe and programmers know
> about, but that's a different matter.
What I'm getting at is that we should come to an agreement re: what
these conventions should be. e.g, with io.Writer, the compiler just
knows about:
type Writer interface {
Write(p []byte) (n int, err error)
}
But the docs also say:
Writer is the interface that wraps the basic Write method.
Write writes len(p) bytes from p to the underlying data stream. It returns
the number of bytes written from p (0 <= n <= len(p)) and any error
encountered that caused the write to stop early. Write must return a non-nil
error if it returns n < len(p). Write must not modify the slice data, even
temporarily.
Implementations must not retain p.
My point is just that we need to have a blurb like this somewhere for
each operator we allow to be overloaded; I don't want to see `os.Stdout
<< "Hello, World!"`. And when considering which operators we should
allow to be overloaded, we should consider what the corresponding blurb
should say, and whether it describes something that actually makes sense
to overload.
Given that we'll want a concrete "meaning" for e.g. `<`, even if
only by convention, I don't see that there's any legitimate use for
overloading `>` separately; if `x < y != y > x`, then something is
wrong.
--
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.
