libstdc++: Handling user-defined interlike object in submdspan.

[Luc Grosheintz]

On 9/29/25 2:55 PM, Ville Voutilainen wrote:
> On Mon, 29 Sept 2025 at 15:27, Luc Grosheintz <luc.grosheintz@gmail.com> wrote:
>>
>> Dear libstdc++ devs,
>>
>> While implementing submdspan, I ran into difficulty related to
>> user-defined "integers", i.e. any class that converts to `index_type`
>> (the latter is always a signed or unsigned integer).
>>
>> The user-defined types might not be copyable or only convert to
>> `index_type` from an rvalue.
> 
> Perhaps they should be required to be copyable and convertible from lvalues, and
> if the spec doesn't allow such a requirement, the spec should be fixed.
> 
> I find it hard-fetched to have such wrinkles in types that are, for
> all purposes, supposed to emulate
> built-in types as far as possible, like custom number types are supposed to.

That sounds very tempting and would make things easier. I don't
fully know how the spec should be, but I can provide context.

However, if I look at the C++23 parts I seem to see parts that read
like they intentionally allow these wrinkles.

For example:

template<class... OtherIndexTypes>
   constexpr explicit extents(OtherIndexTypes... exts) noexcept;

   Let N be sizeof...(OtherIndexTypes), and let exts_arr be
   array<index_type, N>{static_cast<index_type>(std​::​move(exts))...}.

   Constraints:

     (6.1)  (is_convertible_v<OtherIndexTypes, index_type> && ...) is
     true,

https://eel.is/c++draft/views.multidim#mdspan.extents.cons-6.1

which can be contrasted with:

   template<class OtherIndexType, size_t N>
     constexpr explicit(N != rank_dynamic())
       extents(const array<OtherIndexType, N>& exts) noexcept;

   Constraints:

     (9.1) is_convertible_v<const OtherIndexType&, index_type> is true,

https://eel.is/c++draft/views.multidim#mdspan.extents.cons-9.1

In the past we've fixed "bugs" related to this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121061

and raised an LWG issue to make the behaviour more uniform:
https://cplusplus.github.io/LWG/issue4314

which is how I got the impression these are wanted wrinkles.

Again I don't know which way it should change; but I like
uniformity. I also like simplicity, I just don't know if we're
allowed to change it now.