InputMultispan and OutputMultispan + basic adoption in RigidArray and UniqueArray#579
InputMultispan and OutputMultispan + basic adoption in RigidArray and UniqueArray#579Catfish-Man wants to merge 22 commits intoapple:mainfrom
Conversation
Co-authored-by: Guillaume Lessard <[email protected]>
| @safe | ||
| @frozen | ||
| @available(SwiftStdlib 5.0, *) | ||
| public struct OutputMultispan<Element: ~Copyable>: ~Copyable, ~Escapable { |
There was a problem hiding this comment.
Would be interesting to see if we could add a conversion method that vends you an io_vec from this safely
There was a problem hiding this comment.
ooh that would be nice
Catfish-Man
changed the title
| #endif | ||
|
|
||
| @available(SwiftStdlib 5.0, *) | ||
| extension RigidArray where Element: ~Copyable { |
There was a problem hiding this comment.
I'm surprised this works -- BasicContainers imports ContainersPreview, not the other way round. I expect this will need to get moved to BasicContainers.
Catfish-Man
changed the title
|
I'll take a look at any CI failures, the tests pass locally so they're probably just forgetting to update one of the other build systems |
Sources/ContainersPreview/Extensions/OutputMultispan+Extras.swift
Outdated
Show resolved
Hide resolved
|
|
||
| // Shift elements after the subrange if necessary | ||
| let shiftDistance = addedCount | ||
| if shiftDistance != 0 && subrange.upperBound < count { |
There was a problem hiding this comment.
It looks like this code accounts for the possibility of multiple inline elements, but line 145 above assumes the presence of only a single inline element. Should they be made consistent?
There was a problem hiding this comment.
I really want to generalize the rest of it to support multiple inline elements, but I haven't decided how practical that is. Picking one option definitely seems good though.
| @inlinable | ||
| public init<E: Error>( | ||
| capacity: Int, | ||
| initializingWith body: @escaping (inout OutputMultispan<Element>) async throws(E) -> Void |
There was a problem hiding this comment.
This can run into ambiguity issues when used with the trailing closure syntax. I should figure out what to do about that, because we don't want to penalize the more common OutputSpan cases.
| multispan.append(3) | ||
| multispan.append(4) | ||
| multispan.append(5) | ||
| print("is this thing on? Span count: \(multispan.totalCount)") |
| #endif | ||
|
|
||
| @frozen @usableFromInline | ||
| internal struct MultispanBuffer<Element: ~Copyable> { |
There was a problem hiding this comment.
NIT: Do you want to keep these shared internal types in this file our should we move them into a separate file?
5 participants
This gets us the core "asynchronously create a unique/rigid array with a multi output span"