It’s still a breaking API change to alter the default values in a way that violates existing preconditions. But the current scheme allows changing the defaults when necessary (e.g. the initializer for the default value gains a new required parameter) without breaking support for pre-existing binaries.
1 Like
Oh, that makes a lot more sense.
The example you provided looks quite exotic to me. If I was using that type as an explicit parameter (instead of relying on default value), or I was using it otherwise, and that type got a new required parameter my existing code would still break, so that's itself is ABI breaking change.
Public types can have private initializers, which aren’t part of the ABI.
1 Like
If default arguments were required to be inlined into the caller, then everything they touch must be part of the ABI, either by being public or @usableFromInline. As @ksluder alludes to, this widens the ABI, unnecessarily. Swift generally avoids silently adding things to your ABI. Very few things in Swift default to public or @usableFromInline (synthesised protocol conformances are really the only thing I can think of). As there's nowhere good to put a public or @usableFromInline declaration on default argument expressions, choosing to make them thunks seems like a reasonable and safe default choice.