All-open compiler plugin -> Open-By-Default compiler plugin

1

So yes we have the All-open compiler plugin, reference https://kotlinlang.org/docs/reference/compiler-plugins.html

I am one of those people in the “open by default” camp (we lost, tears were had, moving on …). Without rehashing all the reasons … I look at the “All-Open” compiler plugin and think it is sort of ok but really I don’t want to limit it to specific annotations but instead just be “open by default” where instead you need the explicit final keyword.

Now to me it looks like “open by default” can be done as a compiler plugin when I look at … https://github.com/JetBrains/kotlin/blob/master/plugins/allopen/allopen-cli/src/AllOpenDeclarationAttributeAltererExtension.kt
… assuming I am interpreting that code correctly.

Is anyone in the process of building an “Open by default” compiler plugin?

Any thoughts on if this could / should be an officially supplied compiler plugin?

I realise this is old ground but I just like to be able to create basic test doubles without going open class, open fun, open fun … that seems silly to me. Perhaps there should be a standard @OpenByDefault for those people like me?

2

The key reason why we’re never going to ship something like this as an official plugin is that, as discussed in A bit about picking defaults, open by default breaks smart casts. Opening a class via a compiler plugin is even worse because it breaks smart casts silently: the compiler assumes that it can rely on a property of the code when in fact this property can be violated at runtime. In the specific set of cases supported by the kotlin-spring plugin, this is typically not an issue, but this will become an issue if we support it as a general solution.

3

I realise I might have missed something “large” so I’d love to get a better understanding on this if you (or someone else) has the patience (I appreciate it, thanks in advance). When I say “open by default” I mean open class and open fun (so I’m not talking about var vs val … and having thought some more also want to exclude properties).

Now at this point I have not seen open class or open fun prevent smart casts … so I am likely missing something here.

Does ‘open ones’ here mean open val properties or something else?

To me, I follow the … Smart casts aren't applicable to open properties. Well, in my mind I see the property as a getter/setter method pair so yes I get see the subtle issues involved there. However, I am happy to exclude properties so open fun excludes getter/setter methods.

What I don’t understand is where smart casts don’t work due to open class or open fun (excluding properties). If someone could point me to an example or explain that I’d really appreciate it.

Thanks, Rob.

1 Like