[PATCH v4 0/6] Implement mdspan.

[Tomasz Kaminski]

On Tue, Jul 15, 2025 at 12:56 PM Luc Grosheintz <luc.grosheintz@gmail.com>
wrote:

>
>
> On 7/14/25 08:57, Tomasz Kaminski wrote:
> > Hi Luc,
> >
> > While running the libc++ test on libstdc++ we have found the following
> > issue in our implementation.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121061
> > Would you be interested in looking into fixing this?
>
> Yes, I'll take care of this. Do you know if it's the only issue?
> If it's not clear it might make sense that I learn how to run their
> tests on our code.
>
> >
> > Also, libc++ makes the default constructor of mdpsan conditionally
> noexcept
> > as extension
> > (standard does not require it
> > https://eel.is/c++draft/views.multidim#mdspan.mdspan.cons).
> > We could do the same. Instead of writing a big conditional noexcept
> > specification, I would suggest
> > defaultint the constructor on first declaration:
> >        constexpr
> >        mdspan()
> >        requires (rank_dynamic() > 0)
> >            && is_default_constructible_v<data_handle_type>
> >            && is_default_constructible_v<mapping_type>
> >            && is_default_constructible_v<accessor_type>
> >        = default;
> >
> > And then having default member initializers:
> >      private:
> >        [[no_unique_address]] accessor_type _M_accessor = accessor_type();
> >        [[no_unique_address]] mapping_type _M_mapping = mapping_type();
> >        [[no_unique_address]] data_handle_type _M_handle =
> data_handle_type();
> > We do not want to use "{}" as the samantis is a bit differnt.
> >
>
> Yes, I think it makes sense if those two implementations behave
> the same.
>
It seem that clang defines mdspan::is_(always_)?(exhaustive|unique|strided)
with conditional noexcept.
Given that standard-provided layouts define this funciton as noexcept, it
makes sense to propagate that, for common cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20250715/f8acff99/attachment.htm>