RFC: codify unstable api #429
Conversation
|
I think I like it, but I need to get my head around a couple of the implications -- I'll try and get back to you on this soon! |
lrlex/Cargo.toml
Outdated
| @@ -17,6 +17,10 @@ name = "lrlex" | |||
| name = "lrlex" | |||
| path = "src/lib/mod.rs" | |||
|
|
|||
| [features] | |||
| _unstable_api_key = [] | |||
There was a problem hiding this comment.
Does the "key" suffix have a meaning? Should it just be unstable_api?
There was a problem hiding this comment.
No not really, I was mostly thinking of the value of UnstableApi as a key to unlocking unstable_api, and that this feature basically just makes that value public.
the _ prefix does have effect though, in that I believe it hides the feature from cargo/docs.rs
There was a problem hiding this comment.
Oops, yes, I meant _unstable_api (I assumed that _ was a Python-esque convention, but if it's actually noticed by cargo doc even better!).
There was a problem hiding this comment.
Should be fixed in 505f05c, and did some documentation refinement.
|
Please squash. |
ratmice
force-pushed
the
unstable_api
branch
from
22ca050 to
9f4c40a
Compare
|
Squashed. |
This is an RFC for something that I thought of in the #428 pull request, which codifies the notion of unstable traits and function calls.
Using methods similar to those described by the matrix at, using features to selectively lift the restrictions:
https://predr.ag/blog/definitive-guide-to-sealed-traits-in-rust/
It migrates the couple of methods that are marked unstable in the documentation to take token values indicating their instability.
There are 2 variations of these,
InternalPublicApi, that areinternal, but public by default (used in generated code).UnstableApi, require a feature to enable their visibility so that functions requiring the unstable token can be called.The
UnstableTraitfunction/feature is currently unused, but could be useful for #428.