search

ned14 / outcome

Provides very lightweight outcome<T> and result<T> (non-Boost edition)
https://ned14.github.io/outcome
Other
704 stars 62 forks source link

Variation of OUTCOME_TRY that move-assigns existing object? #228

Closed cneumann closed 4 years ago

cneumann commented 4 years ago

OUTCOME_TRY(localVariable, possiblyFailingCall()); works well for cases where the result is wanted in a newly constructed local. However, when I'd like to assign the success result to preexisting object (e.g. a member variable) I had to introduce a temporary and then move assign the member variable from the temporary. I'm probably missing something, but an OUTCOME_TRY_ASSIGN(memberVariable, call()); that move assigns to an existing object instead of move constructing a new one seems like it would help with this?

It would turn this:

OUTCOME_TRY(foobarResult, makeAFoobarIfPossible());
this->foobar = std::move(foobarResult);

into this:

OUTCOME_TRY_ASSIGN(this->foobar, makeAFoobarIfPossible());

I know there is OUTCOME_TRYX which is more general, but sadly not available everywhere :(

ned14 commented 4 years ago

Probably not quite what you asked for, but better I think. Let me know how you get on.

cneumann commented 4 years ago

Ah, yes, that is better :) Thanks! I'll probably have to wait for the v2.2 release before I can use it, so from that point of view having it available now under a different name would still be helpful (to me at least). Not sure if it's worth the churn of adding a new macro now that becomes immediately deprecated in v2.2?

ned14 commented 4 years ago

v2.1 is a sustaining branch. It really isn't supposed to receive anything but bug or correctness fixes. This change is profound enough that it really requires a lot of testing beforehand. I've already applied the change to the work codebase, and several others, so it'll get plenty of testing before v2.2 enters sustaining end of this year. Obviously I'd welcome any extra testing, but I also totally appreciate a desire to not experience churn.