Description
In purescript/purescript-arrays#212, we received a PR that added the function, sliding :: Int -> Int -> Array a -> Array (NonEmptyArray a)
to the repo. Harry brought up some good points here about how to think through such PRs and whether to merge them. However, the main question that I think worth focusing on is what Harry said here:
as an aside: I think it might be nice to adopt a system like Rust's stability annotations which would make it much easier to iterate on things within the core libraries without introducing too much ecosystem churn, but that's probably quite a big project.
In my understanding, the goal of such annotations is to clearly mark which APIs are stable and won't change and which are unstable and could change drastically. If an API is marked unstable, then we can change it as necessary without needing to make a new breaking change, which typically happens when a breaking-changes compiler release is made. Since we don't currently have annotations in the language, there are a few ways we could implement this idea:
- Create an entirely new library outside of core that follows some naming convention (e.g.
purescript-arrays-unstable
). I don't think I see anything good with this approach because it adds yet another library that has to be maintained and released. - Add a new module to current core libraries called
<Module Prefix>.Unstable
. Anything inside this module can change before it gets "stabilized" by moving it from theUnstable
module to the normal module. Also, any such changes don't count as breaking. Unfortunately, this approach won't work well in some cases if cyclical dependencies arose between modules. - Add another empty type class like
DebugWarning
calledUnstableAPI
that notifies someone that the API is unstable. Ideally, this class would be defined inprelude
so it can be used by all other libraries. This has similar benefits of theUnstable
module idea without the module drawback
The third approach above seems like the best tradeoff.