* std::to_address implementation and std::pointer_traits's static_assert
@ 2021-04-20 13:34 Ion Gaztañaga
2021-04-20 13:36 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Ion Gaztañaga @ 2021-04-20 13:34 UTC (permalink / raw)
To: libstdc++
Hi,
While trying to add contiguous_iterator support for Boost.Container so
that users can use std::span with boost::container::vector, I've found a
possible issue with libstdc++ (not sure about it) triggered when
evaluating the "std::contiguous_iterator" concept.
According to the standard, "std::to_address" should evaluate if
"std::pointer_traits<Ptr>::to_address(p)" is well-formed and call
"std::to_address(p.operator->())" if it is not. However, if "Ptr" does
not define "element_type", std::pointer_traits's static assert triggers:
static_assert(!is_same<element_type, __undefined>::value, "...");
which makes std::pointer_traits sfinae-unfriendly. The standard says
that if element_type can't be deduced, pointer_traits specialization is
ill-formed but I expected that std::to_address would select the
"operator->" way of obtaining the address. Is my expectation correct?
Many thanks,
Ion
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: std::to_address implementation and std::pointer_traits's static_assert
2021-04-20 13:34 std::to_address implementation and std::pointer_traits's static_assert Ion Gaztañaga
@ 2021-04-20 13:36 ` Jonathan Wakely
2021-04-20 19:52 ` Ion Gaztañaga
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2021-04-20 13:36 UTC (permalink / raw)
To: Ion Gaztañaga; +Cc: libstdc++
On 20/04/21 15:34 +0200, Ion Gaztañaga via Libstdc++ wrote:
>Hi,
>
>While trying to add contiguous_iterator support for Boost.Container so
>that users can use std::span with boost::container::vector, I've found
>a possible issue with libstdc++ (not sure about it) triggered when
>evaluating the "std::contiguous_iterator" concept.
>
>According to the standard, "std::to_address" should evaluate if
>"std::pointer_traits<Ptr>::to_address(p)" is well-formed and call
>"std::to_address(p.operator->())" if it is not. However, if "Ptr" does
>not define "element_type", std::pointer_traits's static assert
>triggers:
>
>static_assert(!is_same<element_type, __undefined>::value, "...");
>
>
>which makes std::pointer_traits sfinae-unfriendly. The standard says
>that if element_type can't be deduced, pointer_traits specialization
>is ill-formed but I expected that std::to_address would select the
>"operator->" way of obtaining the address. Is my expectation correct?
No, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
I consider it a defect in the standard that pointer_traits is not
SFINAE friendly, but that's what the current standard requires.
I hope it will be changed for C++23.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: std::to_address implementation and std::pointer_traits's static_assert
2021-04-20 13:36 ` Jonathan Wakely
@ 2021-04-20 19:52 ` Ion Gaztañaga
2021-04-20 20:08 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Ion Gaztañaga @ 2021-04-20 19:52 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: libstdc++
On 20/04/2021 15:36, Jonathan Wakely wrote:
>
> No, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
>
> I consider it a defect in the standard that pointer_traits is not
> SFINAE friendly, but that's what the current standard requires.
>
> I hope it will be changed for C++23.
Hi Jonathan,
Many thanks for your quick and precise reply. And just like Giuseppe
D'Angelo described in the bug comments, I also encountered that defining
both element_type and value_type (which makes MSVC STL happy, libc++
still not tested) meets LWG3446.
So at least for libstdc++ I will specialize std::pointer_traits for
boost::container::vector<>::iterator and will revisit the issue if/when
LWG3446 is applied.
Many thanks again!
Ion
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: std::to_address implementation and std::pointer_traits's static_assert
2021-04-20 19:52 ` Ion Gaztañaga
@ 2021-04-20 20:08 ` Jonathan Wakely
2021-04-20 20:15 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2021-04-20 20:08 UTC (permalink / raw)
To: Ion Gaztañaga; +Cc: libstdc++
On 20/04/21 21:52 +0200, Ion Gaztañaga wrote:
>On 20/04/2021 15:36, Jonathan Wakely wrote:
>>
>>No, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
>>
>>I consider it a defect in the standard that pointer_traits is not
>>SFINAE friendly, but that's what the current standard requires.
>>
>>I hope it will be changed for C++23.
>
>Hi Jonathan,
>
>Many thanks for your quick and precise reply. And just like Giuseppe
>D'Angelo described in the bug comments, I also encountered that
>defining both element_type and value_type (which makes MSVC STL happy,
>libc++ still not tested) meets LWG3446.
>
>So at least for libstdc++ I will specialize std::pointer_traits for
>boost::container::vector<>::iterator and will revisit the issue
>if/when LWG3446 is applied.
It's on the gcc-10 branch as r10-9698, which will be in GCC 10.4:
https://gcc.gnu.org/g:32a859531e854382c18abf0b14a306d83f793eb5
That also includes the recently approved fix for LWG 3541:
https://cplusplus.github.io/LWG/issue3541
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: std::to_address implementation and std::pointer_traits's static_assert
2021-04-20 20:08 ` Jonathan Wakely
@ 2021-04-20 20:15 ` Jonathan Wakely
2021-04-20 20:24 ` Ion Gaztañaga
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2021-04-20 20:15 UTC (permalink / raw)
To: Ion Gaztañaga; +Cc: libstdc++
On 20/04/21 21:08 +0100, Jonathan Wakely wrote:
>On 20/04/21 21:52 +0200, Ion Gaztañaga wrote:
>>On 20/04/2021 15:36, Jonathan Wakely wrote:
>>>
>>>No, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
>>>
>>>I consider it a defect in the standard that pointer_traits is not
>>>SFINAE friendly, but that's what the current standard requires.
>>>
>>>I hope it will be changed for C++23.
>>
>>Hi Jonathan,
>>
>>Many thanks for your quick and precise reply. And just like Giuseppe
>>D'Angelo described in the bug comments, I also encountered that
>>defining both element_type and value_type (which makes MSVC STL
>>happy, libc++ still not tested) meets LWG3446.
>>
>>So at least for libstdc++ I will specialize std::pointer_traits for
>>boost::container::vector<>::iterator and will revisit the issue
>>if/when LWG3446 is applied.
>
>It's on the gcc-10 branch as r10-9698, which will be in GCC 10.4:
>https://gcc.gnu.org/g:32a859531e854382c18abf0b14a306d83f793eb5
>That also includes the recently approved fix for LWG 3541:
>https://cplusplus.github.io/LWG/issue3541
To be clear, it's not been approved by WG21, but LWG voted to move it
to Tentatively Ready a week or so ago. I just haven't updated the
issues list yet, so it's still in "New" status.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: std::to_address implementation and std::pointer_traits's static_assert
2021-04-20 20:15 ` Jonathan Wakely
@ 2021-04-20 20:24 ` Ion Gaztañaga
0 siblings, 0 replies; 6+ messages in thread
From: Ion Gaztañaga @ 2021-04-20 20:24 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: libstdc++
On 20/04/2021 22:15, Jonathan Wakely wrote:
>>
>> It's on the gcc-10 branch as r10-9698, which will be in GCC 10.4:
>> https://gcc.gnu.org/g:32a859531e854382c18abf0b14a306d83f793eb5
>> That also includes the recently approved fix for LWG 3541:
>> https://cplusplus.github.io/LWG/issue3541
>
> To be clear, it's not been approved by WG21, but LWG voted to move it
> to Tentatively Ready a week or so ago. I just haven't updated the
> issues list yet, so it's still in "New" status.
Great, thanks again!
Ion
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-20 20:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 13:34 std::to_address implementation and std::pointer_traits's static_assert Ion Gaztañaga
2021-04-20 13:36 ` Jonathan Wakely
2021-04-20 19:52 ` Ion Gaztañaga
2021-04-20 20:08 ` Jonathan Wakely
2021-04-20 20:15 ` Jonathan Wakely
2021-04-20 20:24 ` Ion Gaztañaga
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).