You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.
A project I'm working on makes use of @_specialize as an alternative to inlining in certain circumstances. It can be a really great tool for getting the best performance with the smallest code size. Unfortunately, it leads to quite a bit of noise in the documentation.
It would be great if there was a way to hide these. @_specialize is irrelevant to anybody who uses an API - essentially what it does is, well, generates specialisations of a generic function, and within the function call, figures out if there's an optimised copy to dispatch to. Basically it's like making the compiler write:
func myFunc<S: StringProtocol>(_ value: S) -> Int {
if let stringValue = value as? String {
return myFunc_specialised_for_string(stringValue)
} else if let substringValue = value as? Substring {
return myFunc_specialised_for_substring(substringValue)
} else {
return myFunc_unspecialised(value)
}
}
The text was updated successfully, but these errors were encountered:
A project I'm working on makes use of
@_specialize
as an alternative to inlining in certain circumstances. It can be a really great tool for getting the best performance with the smallest code size. Unfortunately, it leads to quite a bit of noise in the documentation.It would be great if there was a way to hide these.
@_specialize
is irrelevant to anybody who uses an API - essentially what it does is, well, generates specialisations of a generic function, and within the function call, figures out if there's an optimised copy to dispatch to. Basically it's like making the compiler write:The text was updated successfully, but these errors were encountered: