I would imagine that any type with a two-word name is always going to be seen as a "more specialized" version; it doesn't seem plausible that someone is truly going to wonder whether we think of RigidArray or Array as the go-to "default" for beginners. It's not clear to me a priori that making these types less discoverable as Containers.RigidArray is necessary to drive that point home further.
1 Like
Moving them into a module specifically for containers could make these data structures more discoverable, via both documentation and LSP completion.
2 Likes
...so it sounds like we're not entirely sure whether a separate module would make the types more or less discoverable?
1 Like
It's entirely plausible that both can be true. A separate module may make it harder to find the first such type, but easier to find others once you know that one of them exists. There's something to be said for that sort of finer-grained organization for this sort of functionality.
Personally, I come down (weakly) on the side of having a separate module for these, but I see pretty reasonable arguments each way.
8 Likes
I feel like their primacy is assured by them getting the good names. I think I waver more towards no need for the module, especially if we whittle down to just UniqueArray without RigidArray. We decided to put UniqueBox in the top level Swift module, and it needs a buddy. Looking forward, I expect we'll want to add Small{Array,Dictionary,Set} eventually, as well as Unique{Dictionary,Set} and that feels like the right core set.
2 Likes
for standard library documentation, it is irrelevant if these types are in Swift or in a separate module. Apple API docs merge all standard library modules into one documentation bundle, and Swiftinit displays the cross-module API together naturally.
_Concurrency is merged, yes, but e.g. Synchronization appears as its own top-level technology.
1 Like
Right, my understanding is that the Containers module being discussed here would be in the toolchain but not implicitly imported by the Swift module, making it more like Synchronization, Runtime, and RegexBuilder which require explicit imports, and not like _Concurrency and _StringProcessing which are re-exported by default.
2 Likes
Yes, the Containers module as proposed would be like Synchronization.
Other types that would likely find their way into Containers at some point in the future include Deque, Ordered[Set,Dictionary], Heap, Rope, sorted containers, Unique[Deque,Set,Dictionary], Rigid and Small containers, etc. I think it's worth calling out that most other languages require an explicit import statement to get at container types like this; Swift would be the odd language out in tossing all of them into the default namespace.
8 Likes
it appears as its own module, but the documentation artifacts are merged together. this can be observed, for instance, by looking at the list of conformances for Int, which contains AtomicRepresentable.
But clicking on that conformance takes you to the documentation that is plainly in the Synchronization module: AtomicRepresentable | Apple Developer Documentation
Apple's documentation also shows all the conformances declared on Int from various system frameworks that they own, like CKRecordValueProtocol and Plottable, so I'm not sure what case is being made here that's relevant to the Swift standard libraries.
1 Like
… that definining constructs in a separate module will not hamper discoverability of their API documentation because Apple merges documentation artifacts? yes they do dump other things besides standard library modules into their documentation megabundle, but that’s completely additive with respect to the standard library modules.
Apologies for the late feedback here, but having given a closer look at the proposed names, is there a reason that the replace(removing:...) family of methods are not named replaceSubrange(_:...) instead?
That would align with the established name replaceSubrange(_:with:) already used in RangeReplaceableCollection, and would also align with the removeSubrange(_:) methods that are also included in this proposal.
3 Likes