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.