streamly
streamly copied to clipboard
composewell
Expose pre-release APIs
Instead of users importing Internal modules we can just expose all the experimental APIs and mark them Unstable using an annotation (they are already marked as pre-release, do we need a more scary wording?). Ideally we should have a compiler pragma that can warn the users about the stability of the APIs. But we can also do with the haddock annotation and render the documentation of these APIs in a special way to make it noticeable that these are unstable.
We will adhere to versioning policy for such APIs. The only difference from stable APIs is that these can disappear or change without notice in a major release, we will not go through a deprecation process for these.
cc @jkoshy
We can use the WARNING compiler pragma to emit a warning when unstable APIs are used.
The Internal namespace is confusing, people think that it is really guts of the library and not to be used. Internal modules that contain pre-release/unstable APIs can be moved to the Streamly.Unstable.* namespace. And those that are really internal to the library and never to be used by the users can stay in the Internal namespace and can possibly be even hidden by cabal.
I don't like the idea of hiding modules. Everything should be provided for use. We can however somehow differentiate between internal stuff that can be used (unstable). Having 3 namespaces is a pretty huge overhead (Streamly vs Streamly.Internal vs Streamly.Unstable). We will need to define Internal and Unstable and stuff. We can however mark APIs as Pre-release, Released, etc. The UI can mark them accordingly maybe?
