After @hborla's work on operator typechecking, I think it's a good time to revisit my old proposal, SE-0220, for inclusion into the standard library.
For those who aren't aware of the backstory, this proposal was pitched, reviewed, accepted, and had its implementation merged a few years ago. However, it caused issues with typechecking (namely,
.count the integer and
.count as a reference to the function
.count(where:) were getting mixed up and causing bigtime slowdowns when figuring out which version of operators to use), and it was reverted. Holly fixed the typechecking issue a little while ago, and I'd love to see if we can reintroduce this functionality.
This is great!
This also seems like a great candidate for a
@backDeployed(before: macOS XXX), since its implementation doesn't require any special syntax or functions.
Unless I'm mistaken, this method could be always-emit-into-client. Is the standard library now using
@backDeployed exclusively instead now?
Ah, I don't know from a policy perspective.
@_alwaysEmitIntoClient is fine too.
@backDeployed is preferable to an underscored attribute like @_aeic, unless we wouldn’t want to introduce ABI for the new method (which isn’t the case here), or unless we found an issue with
@backDeployed (say, if it prevented specialization or some other important optimization, or if it didn’t support the customary SwiftStdlib availability aliases).
I believe the attribute was carefully designed to avoid such problems, but we haven’t tried applying it for the stdlib’s existing backdeployable API surface, so there may be some unforeseen interactions that are still lurking there. If so, it’s time to find them, anyway!
Sorry to hijack this thread, but is there an article or document somewhere that comprehensively discusses
@_alwaysEmitIntoClient and friends?