The scoping functions (`let`, `apply` , `also` et...

# announcements

[Nick]

The scoping functions (let, apply , also etc.) use contract which is marked as @Experimental. @Vsevolod Tolstopyatov [JB] suggested to not use shared flow in this

video▾

from the past event as SharedFlow was still experimental. He specifically pointed out to wait for a stable version if you work for a bank. Well, I currently work for a bank and I am told not to use anything marked as @Experimental . Since everything in standard.kt uses contract, does this mean these functions aren’t stable either?

[Javier]

Contracts are used everywhere, I think he was saying you should not use public experimental APIs, that functions are public but not annotated as experimental

[ephemient]

contracts are experimental in that the API is not declared stable, e.g. may need changes on upgrade

[ephemient]

stdlib will never be out of sync with itself though

[ephemient]

the user-facing API of let, apply, also, etc. will not change. how it's implemented internally may

[Javier]

@ephemient but the changes will be internal, the functions usage should not change...

[ephemient]

yep, I think we're in agreement

[Joost Klitsie]

Also I think contracts are a "dangerous" thing to use, as it is easy to abuse. But if it is in the hands of a professional (aka within the Standard lib) it is safe to use. Basically, the compiler trusts that what you write is the truth without a need for verification so it is easy to mess up.

[Vsevolod Tolstopyatov [JB]]

does this mean these functions aren’t stable either? !

No, these functions are completely safe to use and stable for a long time.

When using experimental API in stdlib, we basically have two options: propagate it (forcing users to opt-in) or to opt-in by ourselves.

And when we opt-in to some experimental API by ourselves in our stable functions, we actually commit to the following invariant: “it doesn’t matter how this experimental API is going to change, it won’t affect you in any way and we will make sure of that”.

Stability of the non-experimental API is our first priority, so even if these contracts cease to exist (it’s not going to happen, just to give you an example), stable stdlib functions are going to work the same way they work now even if we have to if every single stdlib declaration in the compiler 🙂

[Nick]

Thanks for the detailed response. When I see experimental, I think of it as it could introduce bugs in an app (just like SharedFlow). Since contracts is experimental, wouldn’t that jeopardize the stability of anything that uses it?

[Vsevolod Tolstopyatov [JB]]

When I see experimental, I think of it as it could introduce bugs in an app

It’s not the best perception of the experimental API. Experimentality (and it always written in the corresponding annotation documentation) means that “we are not sure in this API design and may want to change its name, function signatures or function contracts”.

Typically, when you are using stable API from library X (whether it’s stdlib, coroutines or whatever else), you expect that you can freely bump your dependency version and nothing will be changed. Maybe there will be new API, or performance improvements, or bug fixes, but old code should work as before.

That’s not true for experimental API, you can update your dependency and suddenly your code no longer compiles because, let’s say, SharedFlow was renamed to BrandNewSharedFlow and now you have to fix it in order to update. Or some function throws different kind of exception.
It’s now your responsibility to carefully read the changelog and re-test the code that is using experimental API