Support for reference_wrappers in make_xxx
- Dominant language
- C++
- Stars
- 1.9k
- Forks
- 225
- PR merge metrics
- No merged PRs in 30d
Description
Right now, containers are documented as not supporting references at all. First, this should be changed because most containers are able to hold references. Furthermore, it would be nice to add support for `reference_wrapper` in `make_tuple`, like `std::make_tuple`. Specifically, `hana::make_tuple(std::ref(x))` should create a `hana::tuple` instead of a `hana::tuple>`.
Things I'm worried about:
- Compile-time cost of adding even more machinery to `make_tuple`. This will have to be benchmarked to be sure.
- Compile-time cost of including `` in such a fundamental header. This has to be benchmarked too, and we can probably cheat with a forward declaration otherwise.
As a motivating example for this feature, consider the following:
``` c++
struct Person {
std::string name;
};
auto xs = hana::make_tuple(Person{"Bob"}, Person{"John"});
auto ys = hana::transform(xs, [](Person& p) {
return std::ref(p.name);
});
// Right now, ys contains reference_wrappers, which is hard to manipulate.
// This feature would give us the desired intuitive behavior.
```
Containers that should probably support this feature if we decide to go forward:
- `tuple`
- `set`
- `map`
- `pair`
- `optional`
- `lazy`?
As for `basic_tuple`, I think it is better to keep it as basic as possible for performance reasons. I don't think anybody using `basic_tuple` would expect that kind of sugar anyway.
Contributor guide
Research direction
Start at the make_tuple entry point and compare the stated std::make_tuple/reference_wrapper behavior across tuple, set, map, pair, optional, and possibly lazy; basic_tuple is explicitly out of scope. Benchmark the compile-time costs of the added machinery and dependency, then establish the supported container set and expected reference behavior before considering the work done.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend-api-design, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100