Here's a way I've had to address "the two armies problem" and the apparent
need for resource leakage:

There needs to be a layer between the application and the unreliable parts
of the environment, even for something trivial like a socket. For weird
things like IO on Windows (userland resources tied to IRPs), you have to
give it a separate playpen - marshalling all operations and data through an
interface like COM. In the event that you have to deal with flakey
connections in this way, it is better to have a separate process (read:
separate disposable virtual address space) deal with the inevitable OOM,
and the main application itself deal with the QoS issues by re-starting
that process or processes as required. Environment flaws aside, there is
generally a better chance that starting a separate process will succeed
than trying to design a single-process system that can recover from
arbitrary resource loss. This is the same way drivers deal with hardware
abstraction and communication with userland applications anyway.

Not an elegant answer, but its the only way to deal with the "forced
leakage" problem and, outside of operating system flaws, guarantee 100%
uptime.

Embedded environments are subject to a different scrutiny for which the
discussion might be too far a digression from what can already be inferred
from the above.

To the original question: A fully-featured optional<> is about 300 lines of
code. If the application requires something like an optional<> with the
suggested features, it is well within reason to roll a custom one here. The
whole point of the language and flexibility it grants is that you don't
absolutely have to use the standard library, and I assure you most of the
code dealing with this kind of problem isn't going to fall within the scope
of the library anyway - its just there to make some simple things easier
without assuming too much about the applications consuming it.

I've had to write a few mallocs to deal with weird non-uniform memory
architectures (no, not NUMA, more like slow vs fast vs "only this core",
etc...). No single codebase is appropriate for all applications.

On Wed, Nov 29, 2023 at 11:42 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, Nov 29, 2023 at 11:08 AM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > On Wed, Nov 29, 2023 at 3:52 PM Richard Hodges wrote:
> > >
> > > > If you have spawned 6 threads, and if one of them freezes,...
> > >
> > > one would re-write your thread code to include the ability to cancel
> the thread and exit cleanly, surely?
> > >
> > > A well-formed program does not "freeze".
> >
> > How many rodeos have you been to? Operating systems lock up, device
> > drivers lock up, virtual machines lock up. 3rd party libraries lock
> > up. Attend more rodeos.
> >
> > Let's say you set a socket to non-blocking, and then you make a
> > non-blocking read on the socket. Of course, if there's no data waiting
> > there, it should return immediately. But sometimes it doesn't.
> > Sometimes it hangs forever. Now, you can spend time looking through
> > the source code for the device drivers you're using (if they're
> > open-source), and also the operating system you're using (if it's
> > open-source), and the virtual machine software you're using (by the
> > way are _any_ of them open-source?), or you can focus on writing your
> > own piece of software. If you focus on your own piece of software then
> > you have three options:
> >
> > Option No. 1) Let it crash, whatever, let the user restart the program
> > Option No. 2) Gracefully inform the user that something has gone wrong
> > and that the program will now close and immediately re-open. You can
> > also tell the user that the unsaved work has been saved to disk.
> > Option No. 3) Do what I'm doing. . . keep limping forward while you
> > can limp . . . . and then when you drop to the ground, keep crawling
> > forward while you can still crawl, and then when you can't crawl no
> > more, do a slithery snake movement until you can't move at all, and
> > then resort to Option No. 2. Most users will have already achieved
> > their goal before you need to give up entirely.
> >
> > Some programmers get caught up in fairtytale stuff like the object
> > model, playing around with "start_lifetimes_as" and forgetting about
> > how transistors work. I'm gainfully employed writing software with the
> > aim that we don't get phone calls and emails back saying that
> > something isn't working . . . and hopefully not putting a few hundred
> > grand worth of microscopes out of action for week . . . and sometimes
> > I have to compensate for bugs in other people's work . . . plus my
> > boss died suddenly back in May so I'm now doing my own work while
> > trying to reverse-engineer all of his code in order to extend the
> > feature set in line with product management's aspirations -- that's
> > why you'll find me doing things like abandoning an std::future<bool>
> > object.
> >
> > More rodeos.
>
> Here's the problem.
>
> What you want to do is... wrong. It is *not* how one ought to address
> the problem. It may be the necessary way for you in your programming
> context, but it is not broadly the correct way to address the problem.
>
> Coupled with this is the fact that you can *already do what you want*.
> You can use placement-new on `optional::value`. You can use a
> unique_ptr. There are many ways to achieve the effect you want.
>
> So adding this function would not give you any actual power. It would
> only mean that such uses are *sanctioned* by the standard library,
> that we would consider such things to be an OK and reasonable thing to
> do.
>
> Which, as previously stated, is not the case. As such, you need to
> argue that this solution is not wrong, that this is a perfectly
> reasonable and valid thing for a multitude of C++ programmers to want
> to do, and that the standard should be changed to support that.
>
> And you haven't done so. Your argument is that this is the most
> expedient solution, but not that it is actually a *good* one.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>