CP013: Return type for `traverse_topology` (P1795)

[AerialMantis]

Following on from a discussion here and here in prior to P1795r1 about the return type of traverse_topology.

The two alternatives considered were to either have traverse_topology return a vector<system_resource> which requires system_resource to be copy constructible or to have traverse_topology return a ranges::view<system_resource> so that the collection can be further processed lazily after it is returned. We also discussed the possibility of combining the best of both, by having system_resource be semiregular and then returning a ranges::view<system_resource> that is temporarily tied to the lifetime of the system_resource but capable of being assigned to a container such as a vector after any lazy transformation is done.

This also raised the question of whether the topology information contained within a system_topology object is static, I believe we are leaning towards this being the case to avoid the topology being modified asynchronously while it's being inspected.

We should continue the discussion of this and clarify this in P1795r2.

[mhoemmen]

We also discussed the possibility of combining the best of both, by having system_resource be semiregular and then returning a ranges::view<system_resource> that is temporarily tied to the lifetime of the system_resource but capable of being assigned to a container such as a vector after any lazy transformation is done.

I'm OK with that -- the main thing for me is that the proposal clarifies the lifetime of asystem_resource object's association with an actual resource, and the lifetime of the range / vector of system_resource.

[AerialMantis]

I agree, my thinking was that we should reintroduce the wording that we had for this in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0796r3.pdf as we spent quite a bit of time refining that in the context of the new design.