feat: explicit conversion method implementations #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following a convo with JG, I am planning to:
Option
-like semantics onMaybeMultiple
;Vec
-like semantics onMultiple
;Specifically, this means that I want methods implemented on
MaybeMultiple
andMultiple
to contribute to the reason why both of them exist, which is to make the semantics of a container that must contain at least two elements -Multiple
- and an enumeration which can distinctively contain no elements, one element or multiple elements -MaybeMultiple
- explicit in the type system. Implementing convenience conversion functions likeFrom<Vec<T>>
onMaybeMultiple
, for example, does the opposite of this: it makes the conversion explicit, but in code it will always just be a call to.into()
and thus not really visible. Making the call aMaybeMultiple::collapse_vec_into(v)
for turningv: Vec
into aMaybeMultiple
seems a better choice. I hope to find others in the same vein, and I'd of course be thankful for second opinions.