[SERVER-17631] Implement makeStatusWith<T> factory function Created: 17/Mar/15  Updated: 19/Sep/15  Resolved: 24/Mar/15

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 3.1.1

Type: Improvement Priority: Minor - P4
Reporter: Adam Midvidy Assignee: Adam Midvidy
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Platform 1 04/03/15
Participants:

 Description   

This would be analogous to std::make_unique/make_shared/make_optional

There would be two overloads - one that takes a variadic pack and forwards it to T's constructor, returning an engaged StatusWith<T>.

The second would take an errorCode and return a disengaged StatusWith<T>.

This would make it possible to write:

return makeStatusWith<StringData>{str, len};

instead of:

return StatusWith<StringData>{StringData{str, len}};

Tack on work: add an of overload uassertStatusOK that takes a StatusWith<T>



 Comments   
Comment by Githook User [ 24/Mar/15 ]

Author:

{u'username': u'amidvidy', u'name': u'Adam Midvidy', u'email': u'amidvidy@gmail.com'}

Message: SERVER-17631 add makeStatusWith factory function
Branch: master
https://github.com/mongodb/mongo/commit/b17c75a2c0d94db497a7a37e81da7e2343c1da08

Comment by Andy Schwerin [ 20/Mar/15 ]

Do we even need makeStatusWithout<T>? The error forms are implicitly constructible from Status, and StatusWith<T>(code, msg) is less typing than makeStatusWithout<T>(code, msg).

Comment by Adam Midvidy [ 20/Mar/15 ]

Taking an idea from the expected<T, E> proposal (http://www.hyc.io/boost/expected-proposal.pdf), it might make more sense to have two versions.

One that always returns an engaged SW:

template <typename T, typename... Args>
StatusWith<T> makeStatusWith<T>(Args&&... args);

and another that constructs an disengaged SW:

template<typename T>
StatusWith<T> makeStatusWithout<T>(ErrorCode err, StringData reason);

Generated at Thu Feb 08 03:45:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.