[Issue 8469] isSorted fails with predicate "a.length < b.length ? true : a < b"

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=8469


bearophile_hugs at eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs at eml.cc


--- Comment #2 from bearophile_hugs at eml.cc 2012-07-30 07:18:29 PDT ---
(In reply to comment #1)
> That's quite a pickle. The predicate is not a valid sorting relation because
> according to it both "_20" < "_100" and "_100" < "_20" are true (so it's not
> antisymmetric). That's how isSorted operates - it compares adjacent elements
> with the predicate in swapped order.
> 
> We could make isSorted work with broken predicates (at a performance cost for
> everyone), but then people may think if that works sort should works too with
> such predicates etc. etc.
> 
> Best we can is include an assert in isSorted that catches bad predicates in
> debug builds. Thoughts?

Maybe some more advanced languages are or will be able to catch part of the
mistakes in the sorting relation at compile-time.

I suggest to leave sort()/isSorted() as they are, and add an explanation in the
docs of sort() and isSorted() functions that explains the basics of this
situation, what's a bad and good sorting relation.

Generally when the compiler can't catch something at compile-time, the
invariants should be written down in the documentation for the programmer.

One characteristic of the the history programming languages is a progressive
increase of expressivity, that allows to move move more and more information
from the comments written for the programmer to invariants and code that the
compiler is able to understand, verify and use.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------