# Criteria for including of functionality in \`Base\`
**URL:** https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151
**Category:** Internals & Design
**Created:** [November 12, 2022, 6:24am UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151 "2022-11-12T06:24:12Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Lilith](https://discourse.julialang.org/u/Lilith)
#### Post date: [November 12, 2022, 6:24am UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151/1 "2022-11-12T06:24:12Z")
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](https://github.com/JuliaLang/julia/pull/39071) that proposes to add `LogRange`, a useful but unessential type to Base.
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [November 12, 2022, 10:31pm UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151/2 "2022-11-12T22:31:06Z")
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.
---
### Author:  [@Lilith](https://discourse.julialang.org/u/Lilith)
#### Post date: [November 13, 2022, 4:45am UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151/3 "2022-11-13T04:45:56Z")
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.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [November 13, 2022, 8:40am UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151/4 "2022-11-13T08:40:58Z")
Functions are regularly added to Base that could as well live in independent packages according to these criteria. Recent 1.9 inclusions are `stack` and `Iterators.flatmap`, earlier 1.8 were `eachsplit` and `allequal`. I think there are other considerations, mainly the core developers’ judgement of how commonly used these functions would be.
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [November 13, 2022, 9:26pm UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151/5 "2022-11-13T21:26:46Z")
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?”.
---
### Author:  [@mcabbott](https://discourse.julialang.org/u/mcabbott)
#### Post date: [November 13, 2022, 9:33pm UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151/6 "2022-11-13T21:33:00Z")
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](https://github.com/bramtayl/JuliennedArrays.jl) seems to have [1 dependent](https://juliahub.com/ui/Packages/JuliennedArrays/evyIf/0.4.0?page=2)… everyone liked the idea but nobody wanted a dependency? Julia 1.9 will instead have [Slices](https://github.com/JuliaLang/julia/pull/32310) 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 `Iterators.flatmap`.
On `logrange`, maybe worth noting that numpy has not one but two, `logspace` and `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.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [November 13, 2022, 11:13pm UTC](https://discourse.julialang.org/t/criteria-for-including-of-functionality-in-base/90151/7 "2022-11-13T23:13:58Z")
> [@mcabbott](#):
>
> The much-discussed [JuliennedArrays](https://github.com/bramtayl/JuliennedArrays.jl) seems to have [1 dependent](https://juliahub.com/ui/Packages/JuliennedArrays/evyIf/0.4.0?page=2)… everyone liked the idea but nobody wanted a dependency? Julia 1.9 will instead have [Slices](https://github.com/JuliaLang/julia/pull/32310) built-in.
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 `combinedims`/`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?
> [@mcabbott](#):
>
> For sure there are dozens of roll-your-own `allequal` implementations for local use
Would also fit the “implemented in many packages” condition.