On Tuesday, 12 January 2016 at 20:04:26 UTC, Andrei Alexandrescu
wrote:
On 01/12/2016 03:01 PM, John Colvin wrote:
On Tuesday, 12 January 2016 at 19:28:36 UTC, Andrei
Alexandrescu wrote:
On 01/12/2016 02:13 PM, John Colvin wrote:
a<=b and b<=a must also be false.
Would the advice "Only use < and == for partially-ordered
data" work?
-- Andrei
If by that you mean "Only use <= or >= on data that defines a
total
ordering"* I guess it would work, but it has some pretty big
downsides:
1) Annoying to use.
2) You have to use the opCmp return 0 (which normally means
a[<>]=b &&
b[<>]=a) to mean "not comparable".
3) Not enforceable. Because of 2 you'll always get true if you
use >= or
<= on any a pair that doesn't have a defined ordering.
4) inefficient (have to do both < and == separately which can
be a lot
more work than <=).
*would be safer to say "types that define", but strictly
speaking...
I'd be in favor of giving people the option to disable the use
of <= and >= for specific data. It's a simple and logical
approach. -- Andrei
Having thought about this a bit more, it doesn't fix the problem:
It doesn't enable custom float types that are on par with
builtins, doesn't enable transparent "missing-value" types and
doesn't make tsbockmans checked integer types (or other custom
types) work properly and transparently with builtin floats. The
points 1, 2 and 4 from above still stand. Also - the big problem
- it requires antisymmetry, which means no preorders.
One of the great things about D's opCmp and opEquals is that it
separates `a==b` from `a<=b && b<=a`, which enables it to express
types without antisymmetric ordering (see original post for
examples), what you're describing would be a frustrating
situation where you have to choose between breaking antisymmetry
and breaking totality, but never both.
Please consider the second design I proposed? It's small, simple,
has no impact on existing code and works in the right direction
(library types can emulate / act as replacements for builtins) as
opposed to the other way (library types are second class).
