boostorg / boostorg/hana

Support for reference_wrappers in make_xxx

Open
#176 9 comments 0 reactions 0 assignees View on GitHub
feature
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.