Add ArrayStorage.#23
Conversation
saeta
left a comment
There was a problem hiding this comment.
Approving to unblock progress; have a few questions / comments. Thanks for this @dabrahams !!
| if r == capacity { return nil } | ||
| access.withUnsafeMutablePointers { h, e in | ||
| (e + r).initialize(to: x) | ||
| h[0].count = r + 1 |
There was a problem hiding this comment.
Is this the same as:
| h[0].count = r + 1 | |
| h.pointee.count = r + 1 |
Or am I missing something? If so, I think the suggestion might be easier to read.
There was a problem hiding this comment.
Yes, they're the same. I don't have a strong opinion about which is easier to read; they each have strengths. If you have any conviction about this, I'll take your suggestion. But I wish I could write h*.count. And maybe we should have that operator in penguin internals.
There was a problem hiding this comment.
+1 for having an operator. I can put together a PR shortly, and I'll update this code as well.
There was a problem hiding this comment.
We could follow Pascal precedent and have h^.count. I think I prefer * tho.
| /// | ||
| /// This protocol's extensions provide APIs that depend on the element type, and | ||
| /// the implementations for `AnyArrayStorage` APIs. | ||
| public protocol ArrayStorageImplementation: AnyArrayStorageImplementation { |
There was a problem hiding this comment.
Nit: in Swift, I associate Arrays with value semantics, but I didn't see CoW machinery here... would it be better to call this BufferStorageImplementation or maybe BufferImplementation?
There was a problem hiding this comment.
“Array” has the connotations I was looking for: contiguity and homogeneity. “Buffer” doesn't necessarily do that. Also, this follows the convention set in the standard library: “Storage” is a class that provides the storage (https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift#L71), “ContiguousArrayBuffer” is a struct that adds resizability, and “Array” wraps that to provide value semantics.
Happy to use some other terms if you're convinced they're better though.
There was a problem hiding this comment.
I'm fine with following the precedent for now, and we can think harder about this over time. LGTM!
No description provided.