When some composable is marked as ExperimentalFoun...
# compose
e
When some composable is marked as ExperimentalFoundationApi, does it mean it is unstable? Or could the API of the composable change?
f
The annotation means that the API is unstable - can change in future versions. Unstable code in the sense of "if it is working correctly" is signalled by the library version (alpha, beta, rc).
r
IMO, in my cases, it has always been more of a nuisance than any help. I know my situation is obviously different from many others, but the number of times one has to keep adding literally dozens of imports and suppressions to make a small-ish piece of code compile, is almost a meme by this point. Meanwhile on iOS Apple just comes and breaks half your codebase every new release cycle. I am not saying I have a better idea or anything, just an observation 🙂
f
You can opt in for the whole project if you don't want to see some opt in annotation
👍 2
z
We’re moving away from using experimental annotations in most cases, because yea, they’ve mostly just caused tons of headaches for everyone.
👍 2
s
Moving away from them means what, that they are shipped in alphas for people to try and then removed in stable releases? How will this work for stuff like what BTF2 had to do?
z
So far the de facto policy has basically been to introduce all new apis as experimental by default. However, once something has shipped in a stable release, we’ve been assuming it’s used enough that we can’t break it anyway, so there’s no point, so there’s no point in using experimental annotations anyway. There are rare exceptions in the new policy for very special cases, but for something like BTF2 we probably would have just removed the code for the stable releases.
gratitude thank you 1