Date: Mon, 3 Oct 2022 22:13:14 +0200
> 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? If so, is there
anything fundamentally wrong with specialising the type traits instead
(see the second half of my original messages)? I'm not trying to push
for anything, just simply being curious.
Best regards,
Aleksander Miera
>>
>> 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? If so, is there
anything fundamentally wrong with specialising the type traits instead
(see the second half of my original messages)? I'm not trying to push
for anything, just simply being curious.
Best regards,
Aleksander Miera
Received on 2022-10-03 20:13:16