This feels unnecessary for implementations that just take a single delegate argument in the constructor, but as more config options become available (eg threading options in AppleSettings, commit vs apply flag in AndroidSettings), I'd like to consider it more deeply to avoid backward-compatibility issues.
This feels unnecessary for implementations that just take a single delegate argument in the constructor, but as more config options become available (eg threading options in
AppleSettings
, commit vs apply flag inAndroidSettings
), I'd like to consider it more deeply to avoid backward-compatibility issues.kotlinx.serialization did this in preparation for 1.0: https://youtu.be/Azi57n59ICM?t=555 See also https://jakewharton.com/public-api-challenges-in-kotlin/