Improve overload resolution for KnowledgeSource protocols #16
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #16 +/- ##
=======================================
Coverage 83.06% 83.06%
=======================================
Files 9 9
Lines 301 301
=======================================
Hits 250 250
Misses 51 51
Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Looks good to me; would be great to add a documentation for this in the method docs and DocC articles to point people to that behavior.
Thank for putting this in place @Supereg!
Supereg
changed the title
Supereg
changed the title
I added a PR description for a more detailed explanation. I'm not sure if we need to explicitly document this behavior. This rather is an edge case and this PR resolves overload resolution in these cases. What do you think? |
Supereg
force-pushed
the
fix/generally-prefer-computed-ks
branch
from
ef7a6e3 to
0b16cbd
Compare
# Introduce RWLock, ManagedAsynchronousAccess and DataDescriptor ## ♻️ Current situation & Problem This PR adds the `RWLock`, `RecursiveRWLock` and `ManagedAsynchronousAccess` infrastructure that was previously introduced in SpeziBluetooth (see StanfordSpezi/SpeziBluetooth#45 and StanfordSpezi/SpeziBluetooth#47). This changes require the Swift 6 toolchain. Therefore, we increase the required swift tools version to 6.0. This PR introduces the final changes for the SpeziFoundation 2.0 release (assuming #16 is merged beforehand). ## ⚙️ Release Notes * Added `RWLock` and `RecursiveRWLock` * Added `ManagedAsynchronousAccess` * Only require `sending` closure with `withTimeout` instead of a `@Sendable` one. * Add new `DataDescriptor` type. ## 📚 Documentation Updated the documentation catalog, adding a new "Concurrency" topics section. ## ✅ Testing Added unit test for the new components. ## 📝 Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md).
Improve overload resolution for KnowledgeSource protocols
♻️ Current situation & Problem
A
SharedRepositorytypically has multiple overloads for a range of differentKnowledgeSourceprotocols. A knowledge source might provide default values or might be computed. Typically, you only adopt a single knowledge source protocol. However, you cannot prevent users from adopting multiple. This PR improves the overload resolution in these scenarios. All of the specialized KnowledgeSource protocols inherit the baseKnowledgeSourceprotocol. Therefore, Swift resolution will automatically prefer the more specialized type. Problems arise if you accidentally (or on purpose) conform to a computed KnowledgeSource variant and theDefaultProvidingKnowledgeSource. In this case we resolve the conflict and generally prefer the computed knowledge source protocol. We consider a computed knowledge source more specialized than only providing a default value.⚙️ Release Notes
📚 Documentation
--
✅ Testing
Added some unit testing to verify overload behavior.
📝 Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines: