<div dir="ltr"><div>Hi,</div><div><br></div><div>Now that we are done with all the other patches, I cleaned up my inbox,</div><div>and noticed that I haven't responded to this email. </div><div>I hope you are still interested in submitting patches for layouts,</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 30, 2025 at 10:34 AM Luc Grosheintz <<a href="mailto:luc.grosheintz@gmail.com">luc.grosheintz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear libstdc++ developers,<br>
<br>
while implementing layout_left_padded, I noticed some unexpected<br>
behaviour and I'd like to ask for your input.<br>
<br>
<br>
1. Odd mandate/prerequisite for padding value.<br>
<br>
The standard says the padding_value must be representable as<br>
index_type. This immediately precludes using `padding_value ==<br>
dynamic_extent` for any index_type < size_t [1]. Something<br>
similar happens in the ctors that accepts a padding value at<br>
runtime [2].<br></blockquote><div>The padding value at runtime is never expected to be dynamic_extent (this is only for static_extent),<br></div><div>so I think the [2] is correct.<br><br></div><div>For the [1] I think we could be more lax, and incorporate it in the 5.3, and saying that multiplication</div><div>of padding_value (if not dynamic) and 1 if ext.static_extent(0) is dynamic of ext.static_extent(0) first</div><div>into index type. In other words we ignore padding values for ranks 0 and 1.</div><div>I would go for the above relaxed condition in the first implementation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Resolution: If padding_value != dynamic_extent, then ...<br>
<br>
[1]: <a href="https://eel.is/c++draft/mdspan.layout.leftpad#overview-5.2" rel="noreferrer" target="_blank">https://eel.is/c++draft/mdspan.layout.leftpad#overview-5.2</a><br>
[2]: <a href="https://eel.is/c++draft/mdspan.layout.leftpad#cons-4.1" rel="noreferrer" target="_blank">https://eel.is/c++draft/mdspan.layout.leftpad#cons-4.1</a><br>
<br>
<br>
2. Not commonly-convertible.<br>
<br>
Usually, `Layout::mapping<E1>` can be converted to<br>
`Layout::mapping<E2>` if and only if `E1` can be converted to<br>
`E2`. Note that this is for different mappings of the same<br>
Layout.<br>
<br>
For layout_left_padded, the situation is different. If the<br>
extents differ, the following ctor [3] will be used:<br>
<br>
template<typename _LeftPaddedMapping><br>
requires (...)<br>
constexpr explicit(_S_rank > 1<br>
&& (padding_value != dynamic_extent<br>
|| _LeftPaddedMapping::padding_value == dynamic_extent))<br>
mapping(const _LeftPaddedMapping& __other)<br>
<br>
Which means that, for rank > 1:<br>
<br>
static_assert(!is_convertible_v<<br>
layout_left_padded<2>::mapping<E1>,<br>
layout_left_padded<2>::mapping<E2>);<br>
<br>
even if E1 and E2 are convertible.<br>
<br>
At the same time that ctor allows too many conversions if rank <= 1,<br>
including:<br>
<br>
static_assert(!is_convertible_v<<br>
layout_left_padded<2>::mapping<std::extents<int, dyn>>,<br>
layout_left_padded<2>::mapping<std::extents<int, 1>>>);<br>
<br>
static_assert(!is_convertible_v<<br>
layout_left_padded<2>::mapping<std::extents<unsigned int, 1>>,<br>
layout_left_padded<2>::mapping<std::extents<int, 1>>>);<br>
<br>
This second half, I've included in:<br>
<a href="https://cplusplus.github.io/LWG/issue4272" rel="noreferrer" target="_blank">https://cplusplus.github.io/LWG/issue4272</a><br>
<br>
But the issue that they don't convert regularly is unaddressed.<br>
<br>
Resolution 1: Allow conversion if:<br>
- __is_layout_left_padded_mapping_of<_LeftPaddedMapping> is<br>
true,<br>
- same_as<layout_type,<br>
typename _LeftPaddedMapping::layout_type> is true.<br>
<br>
and keep the current conditions otherwise.<br>
<br>
Resolution 2: Leave as is.<br></blockquote><div>I would suggest for the first implementation, leave it as is currently.</div><div>Then it would be great if you could create a RFC patch showing the difference</div><div>of behavior on existing tests.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[3]: <a href="https://eel.is/c++draft/mdspan.layout.leftpad.cons#17" rel="noreferrer" target="_blank">https://eel.is/c++draft/mdspan.layout.leftpad.cons#17</a><br>
<br>
<br>
3. Generic Observation: Missing CTADs<br>
<br>
There's no deduction guides for mappings, e.g.:<br>
<br>
std::layout_left::mapping(std::extents<int, 2>{});<br>
std::layout_left_padded<1>::mapping m(ml); # Ugly error.<br></blockquote><div>This seems like a feature request more than wording issue, </div><div>you could send the note to the paper authors of layouts. I find them very responsive.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Kind regards,<br>
Luc<br>
<br>
</blockquote></div></div>