Median

[1-877-547-7272]

I think discussing SE-0177 is appropriate here since the median functions without a variadic parameter are essentially just clamping functions. I think using a clamped method is a more expressive way to solve this pitch’s motivating problem. And it would potentially be even more expressive if we add a mutating variant as well as support for partial ranges.

Based on this post, it seems that the reason the original pitch was returned for revision is (a) because the implementation wasn’t compatible with the latest version of Swift at the time, (b) the implementation wasn’t generic over RangeExpression, and (c) there were concerns about the proposal not meeting the bar for being included in the standard library. However, I don’t think these reasons really apply today since (a) we can easily create a version of these functions that works in the latest version of Swift. Also, (b) now that Swift’s API is stable, it’s more obvious that a generic implementation over RangeExpression isn’t a good way to represent these functions. Finally, (c) since Swift’s API is more stable than it was 4 years ago, the bar for new additions to the standard library has been lowered because we don’t have to worry about refactoring after a dramatic change in the language’s design.

I think that having clamped functions would help improve readability of code (even more than median) without any significant costs. Based on this forum thread, it seems that there are plenty of others who like this design — it just needs a more formal pitch.

---

I do think that having a separate median function for numbers would be useful, but it should be meant for the purpose of statistical analysis, not clamping a value. We shouldn’t have a function that has two separate purposes. I think it’s up for debate whether we should put it in the standard library or in the Swift Numerics package, but it’s something we should have.

---

Tangential discussion about elementary functions in the standard library

@scanon

Swift Numerics, however, does (for both real and complex types). Not everything has to go in the standard library; you have to include a header or library in most languages to use sin and log . It is at least not obvious that Swift should be different.

I think that functions like sine and logarithm are important enough that they should be in the standard library, and not stay limited to Swift Numerics.

The case for mathematical functions in the standard library:

• According to the note at the top of the SE-0246 proposal page, the reason that these functions weren’t put in the standard library is because of compiler limitations, and the note seems to imply that it will be implemented in the standard library when it’s feasible.
• Requiring users to use a separate package for this functionality means that users will have to learn how to use packages and the package manager and all of its associated complexity. Math (with + / - / * / /) is one of the first things people learn how to do in Swift, so this complexity is undesirable. It’s also less discoverable, and I believe that this lack of discoverability leads people to simply use the C functions — if you search the web for “Swift sine” or “Swift logarithm”, you’ll find that every result suggests using C functions, not Swift Numerics. I believe this is bad because the C functions aren’t generic (so there are separate functions to handle Float) and because I believe Swift should be taught in a way that doesn’t require the programmer falling back on C.
• IMO we should only keep functionality within Swift Numerics if it’s only helpful within the domain of numerical computing. Simple mathematical functions like sine are used beyond numerical computing (i.e. game design and rendering).
• Just because other languages require an import for some functionality doesn’t mean Swift should require one. For example, C++ and Java require an import for variable-sized arrays (<vector> and java.util.ArrayList), but Swift doesn’t. Swift doesn’t usually force programmers to import a bunch of modules for basic functionality. As another example, importing Darwin / Glibc imports every C header (including math.h!) instead of Swift requiring the programmer to import everything individually.

I think functionality like complex numbers and variable-sized numbers are specialized enough that they should stay in Swift Numerics, but simple mathematical functions should go into the standard library