-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add ArrayStorage. #23
Conversation
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: in Swift, I associate Array
s 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
“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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with following the precedent for now, and we can think harder about this over time. LGTM!
No description provided.