What to do about the new oneto and unitrange methods

[KristofferC]

In #37741, the constructors OneTo and UnitRange were replaced for the generic functions oneto and unitrange in various places. These functions only have one implementation in Base which is that they call their respective constructor. The reason for this seems to be so that the InfiniteArrays.jl package can overload these methods to "hook into" various parts of Julia to support some custom behavior.

One issue with this is that these new methods are completely undocumented and unspecified so it becomes quite confusing when someone edits the code where these methods are. Superficially, it looks like they can be completely removed since they only have a trivial method and are not exposed as public API. The aforementioned PR also caused a regression (#40277) but fixing this is now harder because it is unclear what these methods actually need to do.

It would be good if these methods can be removed so that there is no "unofficial" API that packages hook into. From what I understand the reason these got added had something to do with reducing invalidations but doing so shouldn't really need to expose new API?

cc @dlfivefifty, @timholy

[dlfivefifty]

unitrange can be removed with a bit of redesign. oneto is necessary to support InfiniteArrays.jl without having to do an illegal overload of OneTo .

The rational for adding it is exactly the same as adding the functionality that supported OffsetArrays.jl. And your argument for removal would also apply to removing all features that support OffsetArrays.jl, which are also not included in Base and required many “confusing” hooks. Removing oneto will also break literally all of ApproxFun.jl infrastructure

[dlfivefifty]

Also, the addition of oneto should not have caused the issues with vcat, rather the changes to concat.jl. Possibly the change to mapreduce instead of a for loop to determine the length. I’ll look into it