Converting construction (and assignment)

[roibarkan]

Consider add conversions between any_view objects with different any_view_options. Specifically, I think it should be easy and important to construct any_view with some capabilities from an any_view with more capabilities.
One can also consider something like a ‘dynamic_cast’ that attempts to create an any_view with more capabilities if the type erased object supports it - but it’s more challenging, and not sure it’s worth it.

This will potentially make it easier for APIs that work with any_view objects to better interact with each other

[patrickroberts]

@roibarkan thanks for the suggestion! This was something I had thought about but had dismissed as widening the scope of the proposal too much. Unless I'm missing something, this would require a significant amount of additional vtable entries to facilitate. Consider that we have 40 possible combinations of options right now: iterator concept (5), then sized (2), borrowed (2), and lastly copyable (2). So that ends up being 5 * (2^3) - 1 = 39 "upcast" conversions (in the sense of decreasing capabilities, rather than actual inheritance hierarchy) to support in the worst case, and that's not even considering possible value category conversions for range reference type, or difference type, and so on.

The "upcast" conversions are currently possible, the cost being that it layers the type erasure being applied for each conversion. So, I agree it's useful, but in terms of actual implementation I'm not sure there's an approach that can balance the additional required complexity for efficient conversion well.

[patrickroberts]

And in case a concrete example helps clarify the current situation:

std::vector<int> vec;
any_view<int, contiguous | sized> contiguous_sized = vec; // ok; type erasure
any_view<int, random_access | sized> random_access_sized = contiguous_sized; // ok, but type erasure, not conversion
any_view<int, forward> forward = random_access_sized; // ok; also type erasure

// 3 layers of virtual dispatch :(
for (auto& element : forward) {
  // ...
}

[roibarkan]

Thanks for looking into this.
Maybe I was misunderstood, but my suggestion is that the converting-contructors will not create any extra layers of virtual dispatch - and will just work and have the same overhead as the existing copy/move constructors.
What I'm basically saying is that if we already have an any_view with some specific capabilities - its virtual-table has correct entries for all those capabilities, and we should be able to convert it (similar to upcast) to a different any_view with fewer capabilities by simply using a subset of the existing entries in the virtual table.

I think as long as you keep the implementation of any_iterator as it is - where the single base-class isn't bound to the iterator_concept or the any_view_options - implementating such converting constructors should be relatively straightforward. If you attempt to change the design towards inline vtables or towards some inheritance between iterator-types - adding such converting constructors can be a little more tricky.

On the motivation front, I think here's an important motivating example is the ability to compose the following two functions - as a way of showing that any_view is a good fit to sit on API

any_view<int, random_access> foo();
bool bar(any_view<int, forward>);
//....
bool result = bar(foo());

Another cool capability that I think can be added once such converting constructor can give us is accurate CTAD when constructing any_view from actual ranges, so code like any_view v { std::vector{1,2,3} | std::views::filter([](int i){return i%2;}); will create a bidirectional any_view.

[patrickroberts]

I think as long as you keep the implementation of any_iterator as it is - where the single base-class isn't bound to the iterator_concept or the any_view_options - implementating such converting constructors should be relatively straightforward.

That's an interesting point, I hadn't realized this would be possible without additional vtable entries.

And I also like the suggestion about CTAD, which the only reason I think it's not currently provided is because the lack of cost-free narrowing conversions like we're discussing now. And if conversion without additional indirection is possible, then I don't see why the proposal couldn't provide a range adaptor for it too since there would be no reason not to provide all possible capabilities by default.

My only concern at this point is whether this puts an unreasonable constraint on possible standard library implementations. In practice, is it useful from an optimization perspective for different specializations of any_view to implement capabilities in a conversion-incompatible manner? Specifically considering the differences that could exist like what @foonathan was suggesting in #17 to reduce the number of necessary vtable entries to implement capabilities for random access iterators.

I suspect this doesn't pose an unreasonable constraint, but I still think it's good to ask.

[foonathan]

My only concern at this point is whether this puts an unreasonable constraint on possible standard library implementations.

Given that any_view has a constructor that accepts a suitably constrained range, and another any_view with more capabilities is a suitably constrained range, such a conversion exists, and whether it does double dispatch or not is QoI.

[roibarkan]

Hi, Is issue #17 and the rest of the 'fused' operations also considered QoI? For reverse_view the wording forces elimination of indirections ( https://eel.is/c++draft/range.reverse#overview-2.1). Does the standard mandate that converting constructors for shared_ptr should not incur an indirection overhead? I the current wording of P3411 forces the extra level of indirection ("Postconditions: *this has a target view object of type all_t<Rng>") Either way, I think (agree with Patrick) that having a better default capabilities via CTAD is enough motivation. As a side note it seems that ranges-v3 does perform the extra indirection, but still has deduction guides for CTAD.

…

On Sun, Oct 12, 2025, 16:48 Jonathan Müller ***@***.***> wrote: *foonathan* left a comment (bemanproject/any_view#36) <#36 (comment)> My only concern at this point is whether this puts an unreasonable constraint on possible standard library implementations. Given that any_view has a constructor that accepts a suitably constrained range, and another any_view with more capabilities is a suitably constrained range, such a conversion exists, and whether it does double dispatch or not is QoI. — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATTOJLWHVVINS3WAUDT5KT33XJLZBAVCNFSM6AAAAACHVXZWVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJUGQ2DSNRZGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[foonathan]

Is issue #17 and the rest of the 'fused' operations also considered QoI?

Yes, they can be implemented without affecting the interface, so assuming the wording isn't too constrained, it's QoI. The standard library doesn't come with performance guarantees.