[pending] Add a MemoryLayout<T>.offset(of:) method for getting the offset of inline storage.

[jckarter]

If a key path refers to inline storage of the root type, this produces the offset in bytes between a pointer to the root and a pointer to the projected storage. Otherwise, returns nil.

Proposal: swiftlang/swift-evolution#818

[jckarter]

@swift-ci Please test

[jckarter]

@swift-ci Please test

[jckarter]

@natecook1000 Mind reviewing my doc comments here too?

[natecook1000]

Thanks—a few notes below!

[natecook1000]

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.

[natecook1000]

This should be withUnsafeMutablePointer since they're modifying an underlying value.

[natecook1000]

I don't think you need the \. here and below, since key is a key path instance, not the path itself.

[natecook1000]

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 of T, the the return value…". After the example you have below, with root and value, we could use your description here of what might disqualify a property from being measured in this way, with an example type like:

struct ProductCategory {
    var name: String
    var updateCounter: Int
    var products: [Product] {
        didSet { updateCounter += 1 }
    }
    var productCount: Int {
        return products.count
    }
    var someAbstractedProperty: () -> () // I can't think of a good example here
}

And then we could point out the valid and invalid properties either in comments or in text. If I'm understanding this right, updateCounter and name would be safe, but accessing properties of name wouldn't—I don't think I included a non-inline property. What do you think?

[karwa]

Is it worth noting in the documentation that non-@fixed_contents structs reserve the right to change properties from stored to computed? If you write code which depends on a non-optional offset for a particular keypath, it might not continue to work in later versions of the library.

[jckarter]

That's an important point, @karwa . I noted that in the proposal, but it may bear mentioning in the doc comment as well.

[DougGregor]

@swift-ci please smoke test and merge

[slavapestov]

@karwa Even @fixedContents structs can change offsets if the types of the fields are themselves resilient.

[natecook1000]

How does this look for that caveat?

  /// When using `offset(of:)` with a type imported from a library, don't assume
  /// that future versions of the library will have the same behavior. If a
  /// property is converted from a stored property to a computed property, the
  /// result of `offset(of:)` changes to `nil`. That kind of conversion is
  /// non-breaking in other contexts, but would trigger a runtime error if the
  /// result of `offset(of:)` is force-unwrapped.