The Rust collect function is really a merge of the current collect cpp function and ranges::to
It could be easy to act in the same way with cpp collect by calling std::ranges::to(R) if range_value_t is not a potential (or for nested case, none of the sub-container values are potential) .
The ability to use one function to either collect the errors in one type and/or construct the final container with one function is an elegant and a paradigmatic way of constructing containers from ranges in rust.
Given the pre-existence of std::ranges::to, this feature is not mandatory. We can use collect if we want to collect the first error and construct type otherwise and ranges::to if we just want to construct containers.
But adding these could make life easier for the user, so he doesn't have to think about whether or not his range contains potential types, by always defaulting to collect if he knows he wants to stop in the event of an error.
This would make collect a more general function than ranges::to, while leaving open the possibility of using ranges::to if the user wants to use all errors or valid values
Conclusion
I think I'll implement it in a branch in the future and leave it open to discussion with users whether this should be the default collect behavior or not.
Personally, I think I'd be inclined to use this version rather than the current default in future projects.
The Rust collect function is really a merge of the current collect cpp function and ranges::to
It could be easy to act in the same way with cpp collect by calling std::ranges::to(R) if range_value_t is not a potential (or for nested case, none of the sub-container values are potential) .
The ability to use one function to either collect the errors in one type and/or construct the final container with one function is an elegant and a paradigmatic way of constructing containers from ranges in rust.
Given the pre-existence of std::ranges::to, this feature is not mandatory. We can use collect if we want to collect the first error and construct type otherwise and ranges::to if we just want to construct containers.
But adding these could make life easier for the user, so he doesn't have to think about whether or not his range contains potential types, by always defaulting to
collectif he knows he wants to stop in the event of an error.This would make
collecta more general function than ranges::to, while leaving open the possibility of usingranges::toif the user wants to use all errors or valid valuesConclusion
I think I'll implement it in a branch in the future and leave it open to discussion with users whether this should be the default collect behavior or not.
Personally, I think I'd be inclined to use this version rather than the current default in future projects.