<@U0B8F96DT>: Regarding the `strictfp` discussion....

# announcements

[abreslav]

@vmironov: Regarding the strictfp discussion.

As it's the first example of a very minor compatibility issue caused initially by a bug in the compiler, I'll explain our position in detail here.
Note that it's not about binary compatibility, only source compatibility. Any application that used to work before, will keep working.
But, as you rightfully mentioned, there may be as many as about 0 people in the world whose code will not compile after this change (and the compiler tells them that the code never worked in the first place).

My take on this is, in short: it's better to fix such bugs, and the sooner, the better.
One good reason is that the issue is growing over time (in a year from now it may be as many as 1 person, not 0, who'll suffer from this change).

With this particular bug it doesn't actually matter either way, and we'll probably fix it more gracefully (reporting a warning for now, and later supporting @Strictfp for classes). But if it mattered a bit more, i.e. real people were confused by it, we'd deploy a breaking fix to prevent the issue from growing bigger.

Of course, when the issue is already so big that many projects are likely to be affected, it's another story.
In other words: Kotlin is a pragmatic language. We maintain compatibility for pragmatic reasons, and if something breaks only theoretically, it does not mean we can't deploy it.

BTW, even very conservative languages like Java are OK with such changes. See this JEP: http://openjdk.java.net/jeps/286. It proposes to reserve val and var so that if classes with such names existed before, the code will break. Why? Because every language update breaks a tiny fraction of code in the world (compilers are extremely complex systems written by humans, unfortunately), and there's no point in being too bureaucratic about it.

Bottomline:
- thanks for your report, we'll see what we can do here;
- such reports are welcome in the future;
- sometimes we will revoke such changes, sometimes we won't (depending on the issue and possible effects its being fixed or not may have).