Date: Mon, 03 Oct 2022 22:41:39 +0100
Hi,
On 3 October 2022 21:13:14 BST, Aleksander Maciej Miera via Std-Discussion <std-discussion_at_[hidden]> wrote:
>
>> On 3 October 2022 10:11:48 BST, "L?n?rd Szolnoki via Std-Discussion" <std-discussion_at_[hidden]> wrote:
>
>>>
>>> Interestingly clang and gcc have different opinion on cases like this. You do have to break the circular dependency (Node is copyable if vector<Node> is copyable, and vice versa), but once you do that, clang is happy with it.
>>>
>>> https://godbolt.org/z/M51z57PGa
>>>
>>> I think gcc is unfortunately right here, but maybe it could be worked around by removing the actual copy constructor with requires, and creating a template "copy constructor" in its place to defer some instantiations.
>>
>> Workaround:
>>
>> https://godbolt.org/z/vqdj5vKTh
>>
>
>Are you also suggesting using similar approach to fix std::vector (if it's even possible this way) or am I overinterpreting?
No, this would require uses within recursive types to modify their copy operations. It would break too much code.
This approach works for new container types, but the use in recursive types is awkward. I'm not sure if the trade-off is worth it for getting correctly constrained copy operations.
> If so, is there anything fundamentally wrong with specialising the type traits instead (see the second half of my original messages)?
I'm not a fan of adding corner cases to APIs this way. If anything it's vector and other similar containers that should be fixed, but I don't think it's possible without breaking too much user code.
> I'm not trying to push for anything, just simply being curious.
>
>Best regards,
>Aleksander Miera
Cheers,
Lénárd
On 3 October 2022 21:13:14 BST, Aleksander Maciej Miera via Std-Discussion <std-discussion_at_[hidden]> wrote:
>
>> On 3 October 2022 10:11:48 BST, "L?n?rd Szolnoki via Std-Discussion" <std-discussion_at_[hidden]> wrote:
>
>>>
>>> Interestingly clang and gcc have different opinion on cases like this. You do have to break the circular dependency (Node is copyable if vector<Node> is copyable, and vice versa), but once you do that, clang is happy with it.
>>>
>>> https://godbolt.org/z/M51z57PGa
>>>
>>> I think gcc is unfortunately right here, but maybe it could be worked around by removing the actual copy constructor with requires, and creating a template "copy constructor" in its place to defer some instantiations.
>>
>> Workaround:
>>
>> https://godbolt.org/z/vqdj5vKTh
>>
>
>Are you also suggesting using similar approach to fix std::vector (if it's even possible this way) or am I overinterpreting?
No, this would require uses within recursive types to modify their copy operations. It would break too much code.
This approach works for new container types, but the use in recursive types is awkward. I'm not sure if the trade-off is worth it for getting correctly constrained copy operations.
> If so, is there anything fundamentally wrong with specialising the type traits instead (see the second half of my original messages)?
I'm not a fan of adding corner cases to APIs this way. If anything it's vector and other similar containers that should be fixed, but I don't think it's possible without breaking too much user code.
> I'm not trying to push for anything, just simply being curious.
>
>Best regards,
>Aleksander Miera
Cheers,
Lénárd
Received on 2022-10-03 21:41:44