When is a construct that is not required by the compiler or Pkg included in Base? What criteria are used to decide if a PR adding such functionality should be merged? Are these criteria documented?
For example, I’m thinking of a pull request that proposes to add
LogRange, a useful but unessential type to Base.
Generally if it can go into an independent package, it should probably go there first. If that package becomes so widely used and perhaps better maintained within
Base, then perhaps we should include it.
The linked pr could certainly go in an independent package, yet none of the twelve participants in that conversation (including all three of Jeff, Stefan, and Viral) have ever brought up the idea.
Functions are regularly added to Base that could as well live in independent packages according to these criteria. Recent 1.9 inclusions are
Iterators.flatmap, earlier 1.8 were
allequal. I think there are other considerations, mainly the core developers’ judgement of how commonly used these functions would be.
As far as I’ve seen, there really is no policy other than “was the triage call able to agree it was a good idea?”.
Clearly this one is a good idea
People like to say “package first”, but it’s not so clear that this is how it actually goes for small features that have one fairly obvious design. Can anyone name some packages which became “so widely used” in this sense, and were then added?
The much-discussed JuliennedArrays seems to have 1 dependent… everyone liked the idea but nobody wanted a dependency? Julia 1.9 will instead have Slices built-in.
For sure there are dozens of roll-your-own
allequal implementations for local use – easy to be slow & have bugs, not worth a package. Likewise I think it’s unlikely anyone would depend on a package just for
logrange, maybe worth noting that numpy has not one but two,
geomspace. Julia used to have one. (And every plotting package must have one somewhere.) Which I read as understanding that such an object is a natural counterpart to linear ranges. But Julia’s old one had the much-less-useful constructor, the one which saves you typing
10 .^ (range) not the one which saves you any thinking, and hence was removed.
Never heard of that package before. If that’s about efficiently splitting/combining array dimensions, SplitApplyCombine has that and has much more dependents. Other packages also use/define
splitdims-like functions, so in a sense this functionality was already implemented in popular packages - just not in a single commonly-used one.
Maybe, this can be the criteria for inclusion into Base?
Would also fit the “implemented in many packages” condition.