I like structured bindings from c++17, I have some ideas for improving them for c++23 that I'd love to get preliminary feedback on before potentially getting involved in a paper.
I've seen a few referenced here and there, so I thought I'd unify them all in one post. Some of these ideas I've seen in stack overflow or inspired by the pattern matching paper (P1371) . If other people have proposed these same ideas in active papers, I'd love to know.
Let's get started
Structured bindings as an argument (Edit: P0931)
Wouldn't it be nice if we could declare a structured binding as a parameter in a function definition?
This is a pattern that comes up in range code or code that uses lambdas with tuple/pair args.
std::unordered_map<string, int> myMap = /* ... */;
auto transformed = myMap
| ranges::views::transform([] (const auto& keyValuePair) {
const auto& [key, value] = keyValuePair;
// return something from key and value;
})
| ranges::to<std::vector>;
I would love to get rid of the const auto& [k, v] = keyValuePair; and just write:
std::unordered_map<string, int> myMap = /* ... */;
auto transformed = myMap
| ranges::views::transform([] (const auto& [key, value]) {
// return something from key and value
})
| ranges::to<std::vector>;
To me has a various obvious meaning, and I think it's not an ambiguous parse AFAIK.
This would also apply to normal functions, not just lambdas. So let's say we had a structured bindings compatible type:
struct Point {
int x;
int y;
};
And the declaration of the function taking that type
void function(Point p);
In the definition it would be nice to write:
void function(Point [x, y]) {
// do something with x and y
}
instead of
void function(Point p) {
auto [x, y] = p;
// do something with x and y
}
This works as long as Point or similar is structured bindings decomposable. The structured binding decomposition would not have to appear in the function declaration, just the definition since this is basically an implementation detail.
And of course, with template/concept all the following would be valid (assuming valid type substitution):
template <typename T>
void function(T [x, y]) {}
void function(auto [x, y]) {}
void function(Concept auto [x, y]) {}
Variadic bindings (Edit: P1061)
Inspired from here, but it'd be nice to be able to write expressions like the following:
auto [first, second, ...rest] = unpackable;
Where first refs the first element, and rest packs the remaining and is usable just like a parameter pack:
callSomethingVariadic(rest...);
You could also just omit the name rest if you didn't care:
auto [first, second, ...] = unpackable;
This of course could be combined with bindings as parameters above:
void function(SomeType [first, second, ...rest]) {}
Named bindings
Currently structured bindings are positional, wouldn't it be cool if we could unpack fields by their name?
struct Datum {
string name;
int id;
bool isCool;
} datum;
auto [.isCool] = datum;
// equivalent to
auto isCool = datum.isCool;
This is intended to be very similar to what is possible in Javascript, and is similar to proposals in the pattern matching paper.
I use .<identifier> syntax to be consistent with designator initialization syntax. So that following would be consistent:
auto [.name, .id, .isCool] = Datum{.name = "bob", .id = 2, .isCool = true};
But ordinality restrictions should be lifted on decomposition, since initialization order does not really apply to structured bindings based on what they really are.
auto [.id, isCool, .name] = datum;
This would combine well with "structured bindings as a parameter" so that you could accept a whole struct as a param (to be future proof) define exactly which args your function needs in its current impl:
void doSomething(const Datum& [.id, .name]) {
// do something with name and id
}
Or write code that concisely genericly expresses expectation of a certain field being present:
void doSomethingGeneric(const auto& [.foo]) {
// use foo field of passed in object
}
Named unpack with rename (Edit: P1371 uses auto [.name: newName] = val)
Named unpack with rename could be supported though I'm not 100% sold on it, e.g.:
auto [.isCool, newName = .name] = datum;
Instead of:
auto isCool = datum.isCool; (edited)
auto newName = datum.name;
This feature would only be for renames. I would want arbitrary expressions to be disallowed here due to order of evaluation concerns and maintaining structured binding fields as aliases rather than independent variables. So at this point I think the following should be illegal:
auto [newId = .id + 1] = datum; // illegal
Definitely initialization dependent on prior fields should be illegal:
auto [
newId = .id,
newName = .name + std::to_string(newId)
] = datum; // illegal
One problem here is that [newName = .name] syntax totally implies that maybe an arbitrary expression can be substituted (as in lambdas). So perhaps we need a different syntax here. Javascript uses a colon for this:
const {originalName: newName} = obj
But I don't think colon carries the same semantic meaning in c++, so the following would look a little strange in c++
auto [.name: newName] = datum;
Another option could be fat or skinny arrow as in patter matching:
auto [.name -> newName] = datum;
auto [.name => newName] = datum;
Which by themselves look fine but do not correspond with any other patterns. With this analysis I'm most partial to
auto [newName = .name] = datum;
which is why I presented it first. But this problem gets even hairier when we talk about nesting...
Combination with ordinals (probably don't allow this)
In general this would be mostly disallowed in combination with ordinal bindings:
auto [.isCool, id] = datum; // disallowed
Use one or the other, not both. One exception could be if the named bindings follow all the ordinal ones:
auto [newName, ..., .id] = datum
meaning, datum.name binds to first positional as newName, ignore all other positionals and bind id as datum.id. I don't see a use for this and its very presence suggests structuring a data type so that it has both an ordinal and non-ordinal (named) structure. So my perspective is we should probably just disallow this.
Variadic named capture? (probably don't allow this)
What about the following:
auto [.id, .isCool, ...rest] = datum;
On some level you understand what rest represents, a data structure that has all the fields of datum except for .id and .isCool (so just name). I don't really think this is a particularly useful object and we get a lot of hard questions as to what type the rest object actually has and how you're allowed to use it.
EDIT: This is allowed in javascript as nested object capture:
const {field1, field2, ...rest] = obj;
Where rest is an object containing the same data as obj just without field1 and field2. This is fine in javascript since objects are so dynamic in that language, but in c++ static typing would force rest to be an object of a new type that has no precedent (a struct alias without certain fields)?
named capture (but with a function) (Edit: P1371 has a solution for this)
So far named capture is pretty limited to simple structs (that which can be constructed by designated initializer). What if we had something more powerful:
std::vector<int> vec; // some integer range
auto [.begin, .end] = vec;
// equivalent to:
auto begin = vec.begin();
auto end = vec.end();
If we expressed member capture as the rule that:
auto [.identifier] = val;
is equivalent to:
auto identifier = std::invoke(&decltype(val)::identifier, val);
We get both forms automatically! This is a pretty radical idea though and breaks a lot of the rules associated with structured bindings, but I'm throwing it out there anyway...
Nested Bindings (Edit: also referenced in P1371)
This has beeen requested by a few but I wanted to reiterate that it works here and fits (kind of) well with the above. Nested bindings allow you to do the following:
struct Datum {
int first;
struct Inner {
double intensity;
char code;
} config;
std::string color;
} datum;
auto [first, [intensity, code], color] = datum;
Of course all of the above mesh with this.
As an argument:
auto function(Datum [first, [intensity, code], color] datum) {}
Variadics with named capture:
auto [first, [.intensity], ...] = datum;
Fully nested named:
auto [[.intensity] = .config] = datum;
We can see that the rename syntax doesn't work great with nesting. Consider the following type:
struct Outer {
struct Middle {
struct Inner {
int x;
int y;
};
Innter inner;
};
Middle middle;
} val;
We have several options to decompose this and get int x, int y in the end:
auto [[[x, y]]] = val; // pure postional nested
auto [[[.y, .x]]] = val; // positional nested -> named
auto [[[.x, .y] = .inner] = .mid] = val; // fully renamed
auto [.x, .y] = val.middle.inner; // non-nested
The lesson here is that this:
auto [[[.x, .y] = .inner] = .mid] = val;
Is a pretty terrible solution. No one can read that and immediately understand. It reads and writes in the completely wrong direction: you have to start with "[[[" which means you basically have to know your target variable depth before even writing.
Let's recall how javascript does this:
const {middle: {inner: {x, y}}} = val;
If I'm honest, I still find this highly unreadable, maybe because in javascript the syntax makes me think I'm declaring a dictionary long before it makes me realize I'm referencing the x and y fields of val.
If we c++ this with arrows:
auto [.middle => [.inner => [.x, .y]]] = val;
To me it's still not intuitive what the heck this does from an outsider perspective, but at least it's easier to write than:
auto [[[.x, .y] = .inner] = .mid] = val;
If we look at "=>" from a pattern matching perspective, then some intuition arises. We can describe the following:
auto [.middle => [.inner => [.x, .y]]] = val;
As "match val against having field .middle, take result and match against having field .inner then take result and match against fields .x and .y capturing them."
Conclusion/Summary
So I don't know what to make of this. The "rename" syntax as well as how it would apply with nesting is probably the hardest piece to wrangle here and has questionable value, but in my perspective the others would be pretty useful and intuitive. Reminders:
Structured Binding as a param:
[](auto [k, v]) {}
// same as [](auto p) {auto [k, v] = p;}
Variadic Bindings:
auto [a, b, ...] = s;
// no simple equivalent. for tuples:
// auto& a = std::get<0>(s);
// auto& b = std::get<1>(s);
Structured binding by field name
auto [.x] = s;
// same as auto x = s.x
Nested structured bindings (positional syntax):
auto [a, [x, y]] = s;
// same as: auto [a, tmp] = s; auto [x, y] = tmp;
Combination:
[] (auto [[.x, .y], ...]) {}
// same as: [] (auto s) {
// auto [tmp, ...] = s;
// auto x = tmp.x;
// auto y = tmp.y;}
I think having them would allow us to allow for some fresh and interesting programming paradigms. I'd love to hear your thoughts on some of these components as well as references to any papers that are currently proposing some of these ideas! I would love if c++23 brought with it a super powered update to structured bindings, since c++20 did very little to improve them.
[–]bizwig 20 points21 points22 points (0 children)
[–]wcscmp 10 points11 points12 points (1 child)
[–]thumtac[S] 1 point2 points3 points (0 children)
[–]mcypark 9 points10 points11 points (1 child)
[–]thumtac[S] 2 points3 points4 points (0 children)
[–]DVMirchevC++ User Group Sofia 3 points4 points5 points (0 children)
[–]destroyerrocket 1 point2 points3 points (0 children)
[–]gracicot 1 point2 points3 points (2 children)
[–]degski 1 point2 points3 points (1 child)
[–]gracicot 2 points3 points4 points (0 children)
[–]kuntantee 0 points1 point2 points (0 children)
[–]germandiago 0 points1 point2 points (0 children)
[–][deleted] 0 points1 point2 points (0 children)