Open cjdb opened 6 years ago
It's a language issue that we don't have an SB-equivalent for existing things.
I'd say that this is NAD.
I think this issue inadvertently asks for something that rhymes with __common_tuple
, so I might investigate if this is possible, and then mention it in P1035R2 if it is relevant.
That is, assuming @caseycarter doesn't convince me to nuke __common_tuple
altogether.
I would love for the need for __commom_tuple
to die. I would also like the tuple
and pair
assignment operators to accept any type that is compatible with the structured binding of the appropriate arity.
This feels more like a feature request than a proper issue to me. LEWG very deliberately chose to break anything tuple
-related when they asked for named return types. It's very much by design that "std::tie
is currently incompatible with foo_result
."
That is, assuming @CaseyCarter doesn't convince me to nuke
__common_tuple
altogether.
It would be silly to add another generic product type with reference semantics to the standard library. If tuple
isn't generic and/or reference-y enough we should fix it. We don't want to duplicate all the support machinery, we really don't want to introduce 8 more overloads of std::get
.
From cmcstl2's partial_sort_copy:
Diagnostic:
A viable solution will possibly need to go through LEWG first, but I am of the opinion that this is a workaround, not the way things should be done:
Proposal 1
Make
copy_result<I, O>
, etc. implicitly convertible totuple<I&, O&>
for non-const
rvalues only.I don't expect people to start misusing this particular feature, but I could be naïve.
Proposal 2
Add exposition-only result types that all result types can inherit from, (e.g.
struct copy_result : __in_out_result<I, O>
), and add a constructor tostd::tuple
for each exposition-only result type:I am not sure of the implications for this one.
Proposal 3
Change
std::tie
so that it returns an object of an exposition-only type that's common to all result types,std::tuple
, andstd::pair
, and provide constructors for this common type.Again, I'm not sure of the implications, and it's potentially a lot of extra work involved. Having said that, it does feel like the best of the three solutions I've thought of so far, since we can have other yet-to-be-invented types take advantage of
std::tie
.