Adding operator overloading case to structure binding

[Logan Song]

According to the C++ standard, structure binding has three cases right now:

1. binding an array
2. binding a tuple-like type
3. binding to public data members

For example:

#include <cstddef>
#include <tuple>

class tag_ptr {
private:
    void* holder;

public:
    explicit operator ::std::tuple<void*, ::std::byte>() {
        return ::std::tuple(ptr(), tag());
    }

    void* ptr() {...}
    ::std::byte tag() {...}
};

tag_ptr tp;

auto ptr = tp.ptr();
auto tag = tp.tag(); //Uhhhh

//error: cannot decompose non-public member 'holder' of 'tag_ptr'
//auto [ptr, tag] = tp;

Assume we have a class tag_ptr. It could store some bits compressed with a pointer, which we couldn't expose it directly.

As we can see, it's very cumbrous to init variables one by one.

But if we relax the restrictions of rule2 to allow binding type which has tuple-like type cast operator.

The code will be more clear and it could make interfaces more graceful.

That's my proposal. :)

[Michał Dominiak]

There is currently a customization point (or, a set of customization points...) for this feature in the language: std::tuple_size, std::tuple_element, and get(). They aren't pretty to use, but I'm not convinced your proposed way to customize the behavior is really better.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d992c1f5-72f1-4127-9b53-3a4d360a58d6%40isocpp.org.

[Ville Voutilainen]

On 21 July 2017 at 17:04, Michał Dominiak <gri...@griwes.info> wrote:
> There is currently a customization point (or, a set of customization
> points...) for this feature in the language: std::tuple_size,
> std::tuple_element, and get(). They aren't pretty to use, but I'm not
> convinced your proposed way to customize the behavior is really better.

Right, however, in general, types convertible to types that can be
structured-bound aren't supported by structured
bindings. If you have
struct X : tuple<int, int> {};
you can't do structured bindings on it.

On the other hand, allowing conversions gets tricky; what if I have
data members in X? Then it 'obviously' shouldn't
do structured bindings via a conversion to tuple, so what we would get
via the conversions is not necessarily better.
It would certainly make the rules more complex.

> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSxx8TBEC%2BbdPr%2BMnZPBYvZKrFK350zOnwE7U7Ug0BmmQ%40mail.gmail.com.

[Nicol Bolas]

... why? Why go through the intermediate `tuple`? If you have the ability to add `operator tuple` overloads, then you have the ability to add the `get/tuple_element/tuple_size` machinery to your type.

Alternatively, why not simply have a `decompose` member function that returns said `tuple`?