I haven't lead a lot of proposals, but did learn it's reasonable to have them as lightweight as possible, especially when it comes to these orthogonal additions. This is a universal rule.
The more you propose, the more responsibility and maintenance follows. We might want to make corrections as the review runs and we must implement these overloads to begin with. Sadly, the performance of my laptop doesn't make small tooling changes to Swift a lot easier - I might not have the time but I want to save it regardless. The overloads have a pretty good chance of success, but I would rather have them implemented as an amendment to the accepted proposal than complicating changes during the review having at least some odds they (or the proposal altogether) might still be excluded.
I like though how you mention the overloads as a side note in the gist, without drawing extra attention.
I understand the desire to keep things minimal, but I think that the overload defaulting to < should be included in the proposal. When talking about choosing argument labels you say:
Nevertheless, the author is convinced in the superior importance of preserving API uniformity and consistency with existing API the Standard Library developers have worked so hard to keep.
which applies equally to this matter, in my mind. It is also much easier for reviewers or the core team to say “this overload doesn't pull its weight” and remove it from the accepted proposal than it would be to make everyone involved go through a second proposal to make this very minor addition in future.
This is about the importance of avoiding discrepancy in API uniformity in a resilient library when introducing changes. The overloads are a uniform but peripheral addition.
I will make sure to inform the core team to consider and include the overloads to the accepted proposal in case of a positive outcome. Again, we excluded them from the main proposal not because we are opposed, but to save time. Let's get the proposal accepted to begin with. If that happens and everyone agrees on the overloads as well, they will be accepted with the rest and implemented.
@cal Though, if you are still willing to include and implement the overloads now, feel free to.
That's one way to think about it. To me you would be creating discrepancy because I think of the current sort/sorted and their overloads as a single thing (and indeed they presumably would be if there was some sort of “conditional default argument” feature in Swift). I'm a little confused about the time argument, because the overloads seem very simple to write (they can just call your current implementations with <like the current sort/sorted do). And it seems strange to me procedurally to have something in “Future Directions” that you half expect to be accepted in the current proposal.
I was talking relative to ABI stability rather than subjective opinions.
FWIW, it is not as simple as the implementation itself. It takes some time to shape a well-written documentation section. Right now, I don't need a clean build for all the tooling, but it already takes a ridiculous amount of time to build the stdlib with my resources. We are talking about a couple of hours.
Fair enough, I will clarify and rename that section to «Considerations». Thanks!
Oh, okay, but the text I quoted from the proposal is about API uniformity and consistency, which isn't ABI related. If you don't have time to write the overloads and their documentation then that's fair (though these kind of additive APIs can be developed outside of the standard library entirely to avoid the compile time issue) but I'll be arguing strongly for their inclusion in the proposal review. Thanks for your work here, and I hope this proposal will be accepted.