Hi everyone, As far back as I remember (Kotlin 1.3.40 or so?) the Contracts API has been part of th...

# stdlib

[Ryan Smith]

Hi everyone,

As far back as I remember (Kotlin 1.3.40 or so?) the Contracts API has been part of the standard library, most notably in Preconditions.kt as part of the implementation of check{,NotNull} and require{,NotNull} et al.

Today I discovered I can write similar blocks in my own code like this as long as I opt-in for `@ExperimentalContracts`:

fun checkSomeType(value: SomeSuperType) {
    contract {
        returns() implies (value is SomeType)
    }

    check(value is SomeType) {
        "error"
    }
}

My question is multi-faceted. Has the contracts API always been "experimental"? If so, what's left for it to become "stable" given how long it's been around? If not, is it marked "experimental" because it's becoming part of the public standard library API?

[ephemient]

yes, it has been experimental for as long as you've been able to use it https://youtrack.jetbrains.com/issue/KT-25495

[ephemient]

AFAIK: the ABI is effectively stable, because stdlib uses it. but they don't want to commit to supporting the particular DSL yet, so it remains experimental

[Ryan Smith]

I see, thanks for the insight! From the ticket you linked it looks like I've been able to use it as long as I've been working with Kotlin and just never knew it!

[Ryan Smith]

More likely, never came across a reason to

[dmitriy.novozhilov]

Contrast are experimental in terms of syntax, all existing kinds of contacts are stable and are not subject to change
After 2.0 we plan to stabilize this feature by introducing new syntax

[Ryan Smith]

Very cool! Will there be a preview of the new syntax before then?

[dmitriy.novozhilov]

Sure. I think it will be available in 2.0.20, but can not guarantee that

[Youssef Shoaib [MOD]]

Are there any design documents (or even rough sketches) in terms of what that syntax may look like? I'd be quite interested, especially if it requires adding new syntactic features.
Also, food for thought, you might want to delay contract stabilisation if it's similar to its current form (a DSL with a receiver) until context receivers come out, because then you can make the ContractBuilder a context, and thus remove the need to add the label to this in returns() implies (this@myFun is X)

[dmitriy.novozhilov]

AFAIK there will be showcase of new syntax in keynote on KotlinConf
Problem with qualified this is solved in new syntax