[Review] Add a Lazy flatMap for Sequences of Optionals


(Dave Abrahams) #1

Hello Swift community,

The review of “ Tuple comparison operators” begins now and runs through Tuesday, December 22. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Dave Abrahams
  Review Manager


(Paul Ossenbruggen) #2

The title of this email seems a little off, it does not match the enclosed proposal, but responded to the proposal enclosed which is the Tuple comparison proposal.

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

It does seem like a good interim solution until a more general approach can be made that supports N-arity.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. It is not great that these are not easily compared.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Nothing that would influence this.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal.

···

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Dave Abrahams
  Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Curt Clifton) #3

  * What is your evaluation of the proposal?

The proposal should be approved.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Although there's an increase in the runtime size, it's minor at the proposed arity. It will also be at least somewhat offset by individual apps, etc., no longer needing to define their own tuple operators.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This feels like a reasonable first step towards Haskell's `deriving (Eq, Ord)`.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I did a quick re-read of the proposal and have read the thread leading up to it.

— Curt

···

On Dec 21, 2015, at 2:03 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:


(Dave Abrahams) #4

The review of SE-0015 “Tuple Comparison Operators" ran from December 21–22, 2015. The proposal has been accepted for Swift 2.2.

  https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md

Thank you to everyone who participated in the review process! A candidate implementation of this proposal, which may be merged pending evaluation, is at https://github.com/apple/swift/pull/408.

-Dave


(Erica Sadun) #5

This is the Swift-Evolution equivalent of "The proposal was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.'"

-- Erica

···

On Dec 21, 2015, at 2:30 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

The title of this email seems a little off, it does not match the enclosed proposal, but responded to the proposal enclosed which is the Tuple comparison proposal.

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

It does seem like a good interim solution until a more general approach can be made that supports N-arity.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. It is not great that these are not easily compared.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Nothing that would influence this.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal.

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Dave Abrahams
  Review Manager

<open.gif>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #6

Yes, you're quite right, though "a little" is a very generous understatement. My apologies to all. Please fix the subject line in your replies if possible.

-Dave

···

On Dec 21, 2015, at 1:30 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

The title of this email seems a little off, it does not match the enclosed proposal, but responded to the proposal enclosed which is the Tuple comparison proposal.


(Lily Ballard) #7

And the implementation landed as well: https://github.com/apple/swift/pull/408

-Kevin Ballard

···

On Wed, Dec 23, 2015, at 05:01 PM, Dave Abrahams via swift-evolution wrote:

The review of SE-0015 “Tuple Comparison Operators" ran from December
21–22, 2015. The proposal has been *accepted* for Swift 2.2.

https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md

Thank you to everyone who participated in the review process! A
candidate implementation of this proposal, which may be merged pending
evaluation, is at https://github.com/apple/swift/pull/408.

-Dave

_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #8

Congratulations Kevin! My tuples thank you from the bottom of their arity.

-- E

···

On Dec 23, 2015, at 6:01 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

The review of SE-0015 “Tuple Comparison Operators" ran from December 21–22, 2015. The proposal has been accepted for Swift 2.2.

  https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md

Thank you to everyone who participated in the review process! A candidate implementation of this proposal, which may be merged pending evaluation, is at https://github.com/apple/swift/pull/408.

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #9

Already replied directly with the wrong subject but to keep the vote tally straight: +1.

-- E

···

On Dec 22, 2015, at 12:12 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 21, 2015, at 1:30 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

The title of this email seems a little off, it does not match the enclosed proposal, but responded to the proposal enclosed which is the Tuple comparison proposal.

Yes, you're quite right, though "a little" is a very generous understatement. My apologies to all. Please fix the subject line in your replies if possible.

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dmitri Gribenko) #10

* What is your evaluation of the proposal?

This is a very useful addition to the standard library, implemented
given current limitations of the language (without variadic generics).

The only concern is code size, and it will be mitigated by choosing a
reasonable number of overloads to implement.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

* Does this proposal fit well with the feel and direction of Swift?

Yes. It would be even better if we could make tuples conform to
Equatable, Hashable and Comparable, but we can't do that in the
current state of the language.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Python.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I followed all discussions around the proposal from the start.

Dmitri

···

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Karoy Lorentey) #11

+1

** Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

** Does this proposal fit well with the feel and direction of Swift?

Yes, very much so.

** If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Python’s tuples are equatable and comparable the same way. This feels natural and useful. Rust is another example, and so is Haskell. I’m also very used to lexical ordering of tuples from my studies of mathematics, especially in the computer science branch.

The proposal fails to implement full conformance to Equatable and Comparable (and Hashable), but it’s a nice short-term scratch for an annoying itch.

** How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the thread and deeply considered the objections for an hour or so while shopping for groceries.

** What is your evaluation of the proposal?

Equatable is a no-brainer. Even Wikipedia provides the definition of tuple equality, so that’s clearly OK, I think.

Tuples emphatically aren’t the same as vectors, so I think having them sortable with lexical ordering is fine, and it is very convenient. (I would go so far as to say the same of Arrays.)

Tuple is something of a glue type — I use it when defining a named type would feel too verbose. As such, it is very useful to provide tuples with sensible semantics that make them usable in more places.

I can also recall several instances where not having an ordering on tuples has inconvenienced me while writing Swift code. Having to spell out the comparator for the lexical order is a pain, and it is easy to get it wrong.

It is a shame we cannot yet go the full way and have tuples conform to Equatable, Comparable and Hashable when their components do. The proposal presents a weaker form of this that does not allow the use of tuples as e.g. keys in a Dictionary or an ordered map type, although I often want to use tuples in these places. But at least it allows for easy sorting of arrays containing tuples, which is a step in the right direction.

There is precedent in stdlib today in the form of Optional’s < overload, which is arguably too surprising (especially with string searching APIs returning Optional<Int>s). However, I don’t see a case when the tuple variant could be confusing like that.

The proposal doesn’t mention the nullary tuple, but I think () should also be comparable with itself. (And Void should naturally conform to Comparable/Hashable when that becomes possible.)

···

--
Károly


(Guillaume Lessard) #12

I wholeheartedly support the Equatable (==) portion of this proposal.
I’m quite negative about the Comparable portion; it doesn’t really make sense.

The justification for making Tuples comparable pretty much consists of hand-waving.
Why should (0,3,4) be smaller than (0,5,0)? Beats me.
Why would it be the other way around? Also beats me.

I can vaguely see the utility of Comparable when I squint, but the actual behaviour would require extensive documentation with caveats about it not really making any sense. To overload an operator with a clear meaning with a behaviour with a wishy-washy definition is a bad idea.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes for Equatable.
No for Comparable.

* Does this proposal fit well with the feel and direction of Swift?

Yes for Equatable.
No for Comparable.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used Mathematics during an extensive education in Physics and Engineering, at the end of which I escaped with a Ph.D. from a major institution.

Making arbitrary Tuples Equatable when possible makes sense.
Making them Comparable absolutely does not.

Comparability is domain-specific. The standard library cannot know what an arbitrary Tuple means.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I drew upon my experience. While I feel it’s on solid footing, I would hesitate to call it an in-depth study.

Finally, I would like to note that I would support a free-standing function with a clear name that does the same thing as the proposed overloads of the comparison operator.

Sincerely,
Guillaume Lessard


(Lily Ballard) #13

I wholeheartedly support the Equatable (==) portion of this proposal.
I’m quite negative about the Comparable portion; it doesn’t really make sense.

The justification for making Tuples comparable pretty much consists of hand-waving.
Why should (0,3,4) be smaller than (0,5,0)? Beats me.
Why would it be the other way around? Also beats me.

You're proposing that there isn't a clear reason for it to behave the way it is, but you haven't given any justification for this claim. I say there is in fact a clear reason, and that reason is that lexicographical order is a pretty common assumption.

I can vaguely see the utility of Comparable when I squint, but the actual behaviour would require extensive documentation with caveats about it not really making any sense. To overload an operator with a clear meaning with a behaviour with a wishy-washy definition is a bad idea.

It makes sense in any situation where lexicographical comparisons is appropriate, which I would wager covers most of the times where tuple comparisons in general make sense. Not only that, but providing an easy way to invoke lexicographical comparison using tuples allows people to invoke this behavior easily on arbitrary data when they need it.

It was mentioned in the old proposal thread that providing an equality operator on tuples makes it easy to implement equality on structs by just comparing tuples constructed from the struct fields. Comparison operators have the same benefit. For example:

struct Version: Comparable {
    let major: Int
    let minor: Int
    let patch: Int
}

func ==(lhs: Version, rhs: Version) -> Bool {
    return (lhs.major, lhs.minor, lhs.patch) == (rhs.major, rhs.minor, rhs.patch)
}

func <(lhs: Version, rhs: Version) -> Bool {
    return (lhs.major, lhs.minor, lhs.patch) < (rhs.major, rhs.minor, rhs.patch)
}

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes for Equatable.
No for Comparable.

* Does this proposal fit well with the feel and direction of Swift?

Yes for Equatable.
No for Comparable.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used Mathematics during an extensive education in Physics and Engineering, at the end of which I escaped with a Ph.D. from a major institution.

Making arbitrary Tuples Equatable when possible makes sense.
Making them Comparable absolutely does not.

Comparability is domain-specific. The standard library cannot know what an arbitrary Tuple means.

The standard library cannot know this for equality either. But you still think that makes sense. There's plenty of ways to construct tuples where the meaning of equality of the whole is different than the meaning of equality of parts. And if this distinction is important to capture, you're free to define a struct instead of using a tuple, as you can then provide whatever specific notion of equality (or comparability) you want.

I guess the overall question is, given that lexicographical ordering is a very common ordering, what harm is there in providing a lexicographical ordering operation on tuples? If it doesn't make sense for the tuple in question, then just don't try and compare it. Heck, we provide a comparison operator on strings even though the particular comparison it implements isn't always what you want (for example, it's case-sensitive and you may want case-insensitive comparison) but nobody is arguing that strings shouldn't be comparable.

-Kevin Ballard

···

On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution wrote:

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I drew upon my experience. While I feel it’s on solid footing, I would hesitate to call it an in-depth study.

Finally, I would like to note that I would support a free-standing function with a clear name that does the same thing as the proposed overloads of the comparison operator.

Sincerely,
Guillaume Lessard

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #14

I wholeheartedly support the Equatable (==) portion of this proposal.
I’m quite negative about the Comparable portion; it doesn’t really make sense.

The justification for making Tuples comparable pretty much consists of hand-waving.
Why should (0,3,4) be smaller than (0,5,0)? Beats me.
Why would it be the other way around? Also beats me.

So that there’s a default sort order, e.g. in case you want to unique them. Lexicographical ordering by component is the natural choice, IMO.

I can vaguely see the utility of Comparable when I squint, but the actual behaviour would require extensive documentation with caveats about it not really making any sense. To overload an operator with a clear meaning with a behaviour with a wishy-washy definition is a bad idea.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes for Equatable.
No for Comparable.

* Does this proposal fit well with the feel and direction of Swift?

Yes for Equatable.
No for Comparable.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used Mathematics during an extensive education in Physics and Engineering, at the end of which I escaped with a Ph.D. from a major institution.

Making arbitrary Tuples Equatable when possible makes sense.
Making them Comparable absolutely does not.

Comparability is domain-specific. The standard library cannot know what an arbitrary Tuple means.

That’s why we have versions of sort et. al. that take custom comparison closures.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I drew upon my experience. While I feel it’s on solid footing, I would hesitate to call it an in-depth study.

Finally, I would like to note that I would support a free-standing function with a clear name that does the same thing as the proposed overloads of the comparison operator.

Sincerely,
Guillaume Lessard

-Dave

···

On Dec 22, 2015, at 10:39 AM, Guillaume Lessard <glessard@tffenterprises.com> wrote:


(Tino) #15

The justification for making Tuples comparable pretty much consists of hand-waving.
Why should (0,3,4) be smaller than (0,5,0)? Beats me.
Why would it be the other way around? Also beats me.

I strongly agree that comparison for tuples makes little sense - but I'd choose a different example:
(0, 1) < (1, Any.self)
Both are tuples, they are not equal - but can you bring them into a natural order?
"Yeah, but those aren't tuple of the same type, of course you have to have exact same types for comparison"
Right, but when you want to use tuples of the same type in different places, wouldn't it be better to declare that type officially?

If tuple comparison comes for free: So be it — but I can't see any good use cases for this feature.
Of course, as Objective-C has no tuples, we don't have that much experience with them, but my expectation is that in most cases where order of tuples matters, it will depend on a single member — and there shouldn't be pressure to choose the order of the members just to get comparison for free.

Tino


(Guillaume Lessard) #16

The justification for making Tuples comparable pretty much consists of hand-waving.
Why should (0,3,4) be smaller than (0,5,0)? Beats me.
Why would it be the other way around? Also beats me.

You're proposing that there isn't a clear reason for it to behave the way it is, but you haven't given any justification for this claim.

My job here is to disprove, not to prove. I think that the proposed definition is lacking.

I say there is in fact a clear reason, and that reason is that lexicographical order is a pretty common assumption.

Is lexicographical order the same the world over? No! A “pretty common assumption” is a weak foundation.

As I said earlier: “Finally, I would like to note that I would support a free-standing function with a clear name that does the same thing as the proposed overloads of the comparison operator.”

In other words:
- Provide elementwiseComparison<NTupleOfComparables>(t1,t2).
- Don’t overload <

The free-standing function provides all of the desired convenience, without messing with <

Comparability is domain-specific. The standard library cannot know what an arbitrary Tuple means.

The standard library cannot know this for equality either.

This proposal offers a simple *and strict* definition of Equality. (Is there a stricter definition that doesn’t devolve into identity?) Anyone who needs a looser definition can re-define it for their domain.

Comparability is a different beast. Comparability makes sense with scalars. With groups of values there is a required step to map the grouping onto a scalar score, be it magnitude (like vectors) or secret sauce (like Consumer Reports scores.)

(Note that I was quite deliberate in my choice of tuples (0,3,4) and (0,5,0). As vectors: same magnitude.)

Heck, we provide a comparison operator on strings even though the particular comparison it implements isn't always what you want (for example, it's case-sensitive and you may want case-insensitive comparison) but nobody is arguing that strings shouldn't be comparable.

I don't love using comparison operators on strings (gotchas abound), but at least the problem of alphabetizing words is taught in elementary schools. Not so for ordering arbitrary multidimensional data.

Sincerely,
Guillaume Lessard

···

On 22 déc. 2015, at 14:03, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution wrote:


(Dave Abrahams) #17

The justification for making Tuples comparable pretty much consists of hand-waving.
Why should (0,3,4) be smaller than (0,5,0)? Beats me.
Why would it be the other way around? Also beats me.

You're proposing that there isn't a clear reason for it to behave the way it is, but you haven't given any justification for this claim.

My job here is to disprove, not to prove. I think that the proposed definition is lacking.

I say there is in fact a clear reason, and that reason is that lexicographical order is a pretty common assumption.

Is lexicographical order the same the world over? No!

Yes, the mathematical definition of lexicographical order (the only definition that can apply here) is the same everywhere.

A “pretty common assumption” is a weak foundation.

As I said earlier: “Finally, I would like to note that I would support a free-standing function with a clear name that does the same thing as the proposed overloads of the comparison operator.”

In other words:
- Provide elementwiseComparison<NTupleOfComparables>(t1,t2).
- Don’t overload <

The free-standing function provides all of the desired convenience, without messing with <

Comparability is domain-specific. The standard library cannot know what an arbitrary Tuple means.

The standard library cannot know this for equality either.

This proposal offers a simple *and strict* definition of Equality. (Is there a stricter definition that doesn’t devolve into identity?) Anyone who needs a looser definition can re-define it for their domain.

Comparability is a different beast. Comparability makes sense with scalars. With groups of values there is a required step to map the grouping onto a scalar score, be it magnitude (like vectors) or secret sauce (like Consumer Reports scores.)

(Note that I was quite deliberate in my choice of tuples (0,3,4) and (0,5,0). As vectors: same magnitude.)

Heck, we provide a comparison operator on strings even though the particular comparison it implements isn't always what you want (for example, it's case-sensitive and you may want case-insensitive comparison) but nobody is arguing that strings shouldn't be comparable.

I don't love using comparison operators on strings (gotchas abound), but at least the problem of alphabetizing words is taught in elementary schools. Not so for ordering arbitrary multidimensional data.

Sincerely,
Guillaume Lessard

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

···

On Dec 22, 2015, at 2:44 PM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:

On 22 déc. 2015, at 14:03, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution wrote:


(Guillaume Lessard) #18

Okay. I got sidetracked by “lexicography”. I like to buy dictionaries.

This converges on the problem, though: this-precedes-that is *not* the same as this-is-less-than-that.
(Maybe we were talking about different things.)

Note the signature of sort:
func sort(isOrderedBefore: (T, T) -> Bool) -> [T]

Not “lessThan”, but “isOrderedBefore”.

This proposal would redefine the less-than operator to mean “isOrderedBefore”.
It’s been done with String for the sake of convenience, but it should not be generalized.
(Again, a function isOrderedBefore<NTupleOfComparables>(t1,t2) would be useful.)

Note that there is a proper definition of less-than for vectors. (tuples being generalized vectors).
Under that definition, *every* element of vector 1 must be less-than the corresponding elements of vector 2 in order to establish that vector 1 is less-than vector 2.
Back to my example: ((0,3,4)<(0,5,0)) is false and ((0,3,4)>(0,5,0)) is false.
One may well be ordered before the other.

Cheers,
Guillaume Lessard

···

On 22 déc. 2015, at 18:11, Dave Abrahams <dabrahams@apple.com> wrote:
Yes, the mathematical definition of lexicographical order (the only definition that can apply here) is the same everywhere.


(Dave Abrahams) #19

Yes, the mathematical definition of lexicographical order (the only definition that can apply here) is the same everywhere.

Okay. I got sidetracked by “lexicography”. I like to buy dictionaries.

This converges on the problem, though: this-precedes-that is *not* the same as this-is-less-than-that.
(Maybe we were talking about different things.)

Note the signature of sort:
func sort(isOrderedBefore: (T, T) -> Bool) -> [T]

Not “lessThan”, but “isOrderedBefore”.

This proposal would redefine the less-than operator to mean “isOrderedBefore”.
It’s been done with String for the sake of convenience, but it should not be generalized.
(Again, a function isOrderedBefore<NTupleOfComparables>(t1,t2) would be useful.)

It’s very convenient for “<“ to correspond to the standard strict-weak ordering for a type where possible.

Note that there is a proper definition of less-than for vectors. (tuples being generalized vectors).
Under that definition, *every* element of vector 1 must be less-than the corresponding elements of vector 2 in order to establish that vector 1 is less-than vector 2.
Back to my example: ((0,3,4)<(0,5,0)) is false and ((0,3,4)>(0,5,0)) is false.

Tuples are not vectors. If you want your vector type to have a different ordering semantics, just define a separate vector type.

One may well be ordered before the other.

Cheers,
Guillaume Lessard

-Dave

···

On Dec 22, 2015, at 6:28 PM, Guillaume Lessard <glessard@tffenterprises.com> wrote:

On 22 déc. 2015, at 18:11, Dave Abrahams <dabrahams@apple.com> wrote:


(Guillaume Lessard) #20

Convenient maybe. Is it advisable for a standard library feature? Doubtful.

This is about the definition of <. It means “less than”.
This is why operator overloading has a bad reputation.

I don’t dispute the *usefulness* of the proposed feature; I dispute its proposed *name*.
Is ordering tuples needed so often that unclear nomenclature is advisable? No!

Back to fundamentals: (slightly paraphrased from api-design-guidelines)
- Clarity at the point of use is most important.
- Clarity is more important than brevity.
- Promote clear usage.

< does *not* mean “is ordered before”.
< does *not* have a clear meaning with composite data.

isOrderedBefore is a clear name.

I know that Comparable is documented with respect to sorting; it is unfortunate. Sortable would be a better name, given the way it is documented. Note that (apart from String) the concrete Comparables in the stdlib are numbers, stand-ins for numbers (index) or entities referenced by numbers (code points). String is the salient exception.

The proposed change would redefine < and would be against convention.
Highly unclear.

Cheers,
Guillaume Lessard

···

On 22 déc. 2015, at 19:40, Dave Abrahams <dabrahams@apple.com> wrote:

It’s very convenient for “<“ to correspond to the standard strict-weak ordering for a type where possible.