Date: Tue, 28 Sep 2021 18:37:50 +0200
Hi everyone,
Both structured binding and `std::apply` are two different ways to
accomplish a quite similar function. And both make use of similar
tools: `std::tuple_size`, `std::tuple_element` and `get`, but `get` is
found via ADL in structured binding and found via `std::` namespace
qualification in `std::apply`. Is this difference really intended?
I understand that it is legal to specialize `std::tuple_size` and
`std::tuple_element`, but it's not legal to create additional
overloads for `get` in the `std` namespace. The net result is that I
can expose my custom classes as structured binding friendly, but not
`std::apply`-friendly.
Maybe is there a preference for ADL in language features
(`begin`/`end` in for-range-loop, `get` in structured binding) but not
in library features? Should it be reported as a deffect? (changing
`std::apply` to use `get` by ADL shouldn't break anything)
Thanks in advance for your comments,
Jordi
Both structured binding and `std::apply` are two different ways to
accomplish a quite similar function. And both make use of similar
tools: `std::tuple_size`, `std::tuple_element` and `get`, but `get` is
found via ADL in structured binding and found via `std::` namespace
qualification in `std::apply`. Is this difference really intended?
I understand that it is legal to specialize `std::tuple_size` and
`std::tuple_element`, but it's not legal to create additional
overloads for `get` in the `std` namespace. The net result is that I
can expose my custom classes as structured binding friendly, but not
`std::apply`-friendly.
Maybe is there a preference for ADL in language features
(`begin`/`end` in for-range-loop, `get` in structured binding) but not
in library features? Should it be reported as a deffect? (changing
`std::apply` to use `get` by ADL shouldn't break anything)
Thanks in advance for your comments,
Jordi
Received on 2021-09-28 11:38:04