On Wed, 2023-11-22 at 14:16 +0200, sasho648 via Std-Proposals wrote:
> In my opinion if exceptions were used more it would be worthy to add
> my suggestion - your solution is too verbose.
>

int f() {
  decltype(&func()) ptr = nullptr;
  try {
    ptr = &func();
  } catch(...) {}

  // use ptr here
}

I'm strongly against this proposal, as it introduces the concept of
"uninitialized reference" that didn't exist before. Sure references can
become stale and thus invalid, but they are not invalid right after
their initialisation. This is essentially a null reference.

The pointer makes it explicit that it might have a state other than
referring to an object, and therefore safer. It also makes it possible
(but not necessary) to check for this state.

> On Wed, Nov 22, 2023 at 2:07 PM Lénárd Szolnoki via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > On Wed, 2023-11-22 at 13:56 +0200, sasho648 via Std-Proposals
> > wrote:
> > > Because I only care about the exception thrown at `func()` and
> > > don't
> > > want to have exception handling for the rest of the code.
> >
> >
> > int f() {
> > const auto ptr = [&]() -> decltype(&func()) {
> > try {
> > return &func();
> > } catch (...) {
> > return nullptr;
> > }
> > }();
> >
> > // use ptr here, check for null, dereference, whatever
> > }
> >
> > >
> > > On Wed, Nov 22, 2023 at 1:54 PM Fabio Alemagna
> > > <falemagn_at_[hidden]>
> > > wrote:
> > > >
> > > >
> > > > Il mer 22 nov 2023, 12:50 sasho648 via Std-Proposals
> > > > <std-proposals_at_[hidden]> ha scritto:
> > > > > Ok use-case I was thinking is actually:
> > > > >
> > > > > int f() {
> > > > >
> > > > > try (auto &ref = func()) {
> > > > > } catch(...) {
> > > > > return -1;
> > > > > }
> > > > >
> > > > > // use ref here
> > > > > }
> > > >
> > > > Why would you want to use ref after the whole try-catch block?
> > > >
> > > > If func() does't throw, you can use ref right after its call,
> > > > within the try block itself.
> > > >
> >