Hi Herb, Bjarne, Gabriel,

I heard about Structured Bindings for the first time at CppCon this year, and
I'd like to raise my concerns, esp. since half of the panel was crazy about
them.

I strongly believe that the premise that returning std::tuple from functions
to solve the multiple-return-types problem is good practice, is fundamentally
wrong.

It is not good in any sense of the word. It is horrible. Indeed, it is so
horrible that you felt inclined to add a new language feature just to make it
bearable.

The reaons it's horrible, is because it reverses the C++ principle that the
implementor of a library should have to do the work, not the user.

It reverses the principle by requiring the *caller* to choose the names of the
values returned, when it should be the implementor of the function who chooses
the names.

In conjunction with auto deduction, the caller choosing the names means that
the code becomes brittle in the face of changes to the return type, e.g. when
reordering fields to fill padding holes.

Structured Bindings would be acceptable if, like scripting languages, we
didn't have anything else to work with.

But we do: We can return a struct.

IMHO, the correct solution to the multiple return value problem is to return a
struct with properly named fields, not a pair and not a tuple.

I fear Structured Bindings will lead to an explosion of *really* bad API that
returns std::pair or std::tuple when it should return a small struct with
well-named data members instead, because a) the implementor couldn't be
bothered to pick good names for a return struct, and b) tuples can be defined
on the fly, in the function declaration, whereas structs can not.

I believe there's a proposal for allowing to define structs in function
declarations already, but I failed to find it.

Consider:

   std::map::insert(...) -> std::pair<iterator, bool>

or the other way around, I can never remember, which is a problem that
structured bindings don't solve for me. Yes, in this case using the iterator
as a boolean will fail, but what about algorithms that return multiple
iterators? If you get the order wrong, then you have a bug.

No, map::insert() should have returned a

   struct { iterator iterator; bool inserted; };

so one could say:

   if (map.insert(...).inserted)

or

   auto result = map.insert(...)
   if (result.inserted)

To summarise: I feel that Structured Bindings are too easy to use incorrectly,
because they put the burden of choosing a name for the fields of a return
value on the caller, instead of the implementor, of the function. I'd like to
see the pattern to return structs from functions strengthened, not the anti-
pattern of returning pairs and tuples.

I therefore hope that I can persuade you to reconsider adding Structured
Bindings to C++17.

Thanks,
Marc

--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/201610051238.17863.marc.mutz%40kdab.com.

.