-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[pending] Add a MemoryLayout<T>.offset(of:)
method for getting the offset of inline storage.
#15519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -162,4 +162,41 @@ extension MemoryLayout { | |
public static func alignment(ofValue value: T) -> Int { | ||
return MemoryLayout.alignment | ||
} | ||
|
||
/// Returns the offset of an inline stored property of `T` within the | ||
/// in-memory representation of `T`. | ||
/// | ||
/// If the given `key` refers to inline storage within the | ||
/// in-memory representation of `T`, and the storage is directly | ||
/// addressable (meaning that accessing it does not need to trigger any | ||
/// `didSet` or `willSet` accessors, perform any representation changes | ||
/// such as bridging or closure reabstraction, or mask the value out of | ||
/// overlapping storage as for packed bitfields), then the return value | ||
/// is a distance in bytes that can be added to a pointer of type `T` to | ||
/// get a pointer to the storage accessed by `key`. If the return value is | ||
/// non-nil, then these formulations are equivalent: | ||
/// | ||
/// var root: T, value: U | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need to have four spaces of indentation (five including the initial space after the triple-slash) for a code sample to be recognized. Within the code sample, we also use four-space indentation instead of the stdlib-standard two. |
||
/// var key: WritableKeyPath<T, U> | ||
/// // Mutation through the key path... | ||
/// root[keyPath: \.key] = value | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think you need the |
||
/// // ...is exactly equivalent to mutation through the offset pointer... | ||
/// withUnsafePointer(to: &root) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be |
||
/// (UnsafeMutableRawPointer($0) + MemoryLayout<T>.offset(of: \.key)) | ||
/// // ...which can be assumed to be bound to the target type | ||
/// .assumingMemoryBound(to: U.self).pointee = value | ||
/// } | ||
/// | ||
/// - Parameter key: A key path referring to storage that can be accessed | ||
/// through a value of type `T`. | ||
/// - Returns: The offset in bytes from a pointer to a value of type `T` | ||
/// to a pointer to the storage referenced by `key`, or `nil` if no | ||
/// such offset is available for the storage referenced by `key`, such as | ||
/// because `key` is computed, has observers, requires reabstraction, or | ||
/// overlaps storage with other properties. | ||
@_inlineable // FIXME(sil-serialize-all) | ||
@_transparent | ||
public static func offset(of key: PartialKeyPath<T>) -> Int? { | ||
return key._storedInlineOffset | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this initial paragraph could focus on the happy path: "If the given
key
refers to inline, directly addressable storage within the in-memory representation ofT
, the the return value…". After the example you have below, withroot
andvalue
, we could use your description here of what might disqualify a property from being measured in this way, with an example type like:And then we could point out the valid and invalid properties either in comments or in text. If I'm understanding this right,
updateCounter
andname
would be safe, but accessing properties ofname
wouldn't—I don't think I included a non-inline property. What do you think?