[CXX-939] Non-default-constructibility of document::value frustrates common programming idioms Created: 19/Jun/16  Updated: 07/Feb/24

Status: Backlog
Project: C++ Driver
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Epic Link: C++ Developer Experience Improvements
Quarter: FY25Q2

 Description   

See https://groups.google.com/forum/#!topic/mongodb-user/w193ViKfArU



 Comments   
Comment by David Golden [ 25/Jan/17 ]

Given this has come up again, I think we need to do something more, either in the API or in the documentation to help users avoid frustration. I'm putting this into the "Not Planned" bucket so it's visible in our backlog, but without committing us to specific work.

Comment by David Golden [ 25/Jan/17 ]

This came up again in FREE-120548 ( https://groups.google.com/forum/#!topic/mongodb-user/9aCMUczSXvI ).

Comment by Andrew Morrow (Inactive) [ 19/Aug/16 ]

Given that no consensus has emerged, I'm closing this as won't fix. Users can use stdx::optional for this use case. We can always revisit in the future.

Comment by Andrew Morrow (Inactive) [ 30/Jul/16 ]

https://github.com/mongodb/mongo-cxx-driver/pull/511

Comment by Allan Bazinet [ 22/Jun/16 ]

With reference to the linked discussion, I think that things like exceptions and move semantics exist for reasons that are, indisputably, good ones. One can take an approach of embracing such standards, which allows consumers a choice to wrap the library implementation with something more to their liking, or one can attempt to pretend they don't exist, which is, to me, frankly, a form of collective punishment.

That is, a good library exposes power and flexibility; you might choose to insulate yourself from some of the power or the flexibility, and that's your choice, but at least you can make the choice.

Were it me, I'd probably elect to experiment with the first choice, that is, moved-from semantics, but TBH I'm not sold on the argument of needing a change here; to me, I'd append 'of the past' to the title of this issue.

The examples referenced in the discussion are, for example, indicative of at best a poor understanding of exception handling – if you're treating exceptions as return codes, it's not going to end well. However, allowing moved-from semantics would, seemingly, allow hoisting of the result out of the exception-protected scope without excessive cost should one wish to.

Comment by Andrew Morrow (Inactive) [ 22/Jun/16 ]

alb - As an early user of the driver, I would like to solicit your feedback on this issue. We are contemplating giving bsoncxx::document::value a default constructor (please see the mongodb-user group discussion in the ticket description). There would be two ways to do this:

  • Give a default constructed document::value "moved-from" semantics. The only valid operations would be to assign to it, or destroy it. Cheap, but easy for users to get wrong.
  • Give a default constructed document::value "empty document" semantics, much like a default constructed document::view. Requesting a view from a default constructed document::value would give you a view into an empty BSON document. There would be some cost to properly initialize such a document::value, and it would introduce some cost into the class to account for whether or not the underlying memory was actually owned, or referred to the static empty document.

Thoughts?

Generated at Wed Feb 07 22:00:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.