Make collect able to work on nested range containing potential_type
Option 1
The easiest way of doing that would be to collect the first encountered potential_type and ignore deeper potentials.
Option 2
But it should be possible if potential type are common (ie all optional or expected sharing the same error type) to collect further and collect accross all container into a final container free of all potential types.
The question is : is that worth it? I think the common use case is to coolect once you encounter a potential_type in your range workflow. or to work further on potential_type with .transform, and_then methods and finally collect when all work is done.
Option 3
One final possibilty far more complex but worth mentioning is to collect all potential type in the container into a single potential with potentially a variant error type.
Could be collected in a common potential type : expected<vector<vector<int>>, variant<nullopt, exception>>
But my current view is that this would probably be over-engineering.
Conclusion
I think the first option is definitely needed and easy to implement.
The two other options are potentially powerfull but could make the function too complex for features that are almost never used.
Make collect able to work on nested range containing potential_type
Option 1
The easiest way of doing that would be to collect the first encountered potential_type and ignore deeper potentials.
Option 2
But it should be possible if potential type are common (ie all optional or expected sharing the same error type) to collect further and collect accross all container into a final container free of all potential types.
The question is : is that worth it? I think the common use case is to coolect once you encounter a potential_type in your range workflow. or to work further on potential_type with .transform, and_then methods and finally collect when all work is done.
Option 3
One final possibilty far more complex but worth mentioning is to collect all potential type in the container into a single potential with potentially a variant error type.
For example:
Could be collected in a common potential type :
expected<vector<vector<int>>, variant<nullopt, exception>>
But my current view is that this would probably be over-engineering.
Conclusion
I think the first option is definitely needed and easy to implement. The two other options are potentially powerfull but could make the function too complex for features that are almost never used.
This needs to be discussed further