[stdlib][WIP] Factor out common parts of pointer types and de-gyb #17951
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci please test |
|
@swift-ci please smoke benchmark |
Build comment file:Optimized (O)Regression (21)
Improvement (38)
No Changes (399)
Hardware Overview |
|
Awesome. Thanks! |
|
I think there's more simplification to be done but I'm going to land this on master now since the degybbing makes rebases painful. @natecook1000 this will need some rethinking of how we phrase the docs for stuff that is shared between typed and untyped pointers. |
|
Hmm, this may end up causing doc problems because of the way we treat underscored things as quasi-private when it comes to visibility of docs and/or generated header. I'll take a look at how SourceKit vends these types after the change — is there a reason why Pointer needs to be underscored? |
|
Ah. The main reason for the underscore is that it would need an evolution proposal to turn it from an implementation detail into a publicly-available protocol. And it's questionable whether that would be useful as a public protocol – not clear people outside the std lib need to write code that's generic over different kinds of pointers. They might though, I haven't thought about it much. But I'd rather not pursue that purely for doc generation reasons. |
|
@airspeedswift actually the diagnostics are much better after your changes. The overload lists are shorter and now there's no mention of memory binding. We should never tell "normal" developers to use the memory binding APIs. They only make sense if you're writing a custom allocator in Swift. It's always better to redesign the user-side APIs to use correct pointer types and introduce C wrappers where needed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Redo of #17628
There is a lot of boilerplate across Unsafe{Raw}{Mutable}Pointer that can instead be done via protocol extensions on the already-existing _Pointer protocol, since it's all identical and only relies on access to the underlying builtin pointer. This reduces the actual code to the point where it makes sense to de-gyb the file. Since most of this code is transparent anyway, it should make little difference to performance.