There are plenty of examples of languages that have addressed the obnoxious verbosity of code
like this:
```
temp = ..;
if(!temp) {throw/return/…};
temp2 = temp->something();
If (!temp2) { …}
Temp3 = …
…
```

Not one of these new languages designed a solution for this that made the failure semantics secret
or hidden from the call/use site: they adopted concise syntax or apis to make the common cases
concise and readable, but most importantly that syntax is still _explicit_. In swift the caller side must
distinguish calls to functions that can throw from those that don’t, with explicit syntax to streamline the
“just ignore the exception” common case.

Trying to “simplify” one single example of this kind of code by having having an annotation automatically
adds an `if (…) throw ..` is a clearly bad approach. It’s a new feature that opaquely changes behaviour,
it only “fixes” a specific class of this kind of development problem, it requires exceptions which are both
very slow, and also one of the most frequently disabled C++ features (I recognize there are many in the
committee that believe that this practice should be ignored because it makes the language no longer
c++, but if a new feature is functionally unusable by many of the biggest C++ projects the cost/benefit
ration of the feature from the PoV of compiler developers changes radically).

Ignoring the programmer hostile language semantics this would cause it raises the obvious and
immediate questions of why this is a property of the declaration? This is a property of the function
implementation, not the caller, and we already have `throws()` to ostensibly inform the caller that
a function may throw.

I’ve asked in the past for you to put ensure that your proposals include all the work you have done,
not just what the proposal is, hypothetical implementation details.

Given the volume of proposals you make, it is unhelpful to either committee members or yourself
to be sending these proposals in without including all you work.

Your proposal emails really need to include all the work you’ve done. Trying to abbreviate them so
that the emails are shorter to read is _less_ helpful than including everything you’ve done:

1. A description of the actual problem you’re trying to solve
2. A complete description of your proposed solution
3. Information about how the proposal impacts the language and abstract machine, and if applicable
any new requirements it adds to the abstract machine.
4. The other approaches you considered when developing the proposal, and the issues or trade offs
involved.

The two proposals in this thread have not included complete information for (1) or (2) - you’ve simply
included an one or two of the cases you’ve considered, but not the general problem you’ve been
thinking about. As a result we’re having to read the examples and extrapolate out to the general
problem, and that means we may end up thinking the general problem you’re trying to solve from
the general problem the _you_ are thinking about. That obviously impacts how we think about how
the problem should be addressed, or potentially even if there is a problem, and how we think about
whether your proposal resolves the general issue that we think you’re trying to fix. When we then
try to understand your solution you’re simply providing a single implementation example, but not
the work you did to design the general solution. It’s very hard to read just the implementation of
your solution and reverse back to what you want the general solution to be is.

The proposals you send in consistently fail to include any of the work you did for 3 and 4 above. I
recognize that you might be concerned about sending proposals that are long, I for one would much
rather you send larger emails including the work you did in determining how the proposal interacts
with the language and abstract machine, especially if it adds the new requirements to the abstract
machine (because such changes may immediately rule it out - AM changes are very hard). Similarly
including information about the other approaches you considered to resolving the problem means
that committee members aren’t going to be spending a bunch of time redoing the work you already
did, and aren’t then going to bring up those alternatives or the issues with the proposal that you
have already thought about and addressed.

As with the threads from your other proposals, a lot of the emails are committee members asking
questions, raising issues, or providing alternatives that you have argued against but what else can
the committee do? Despite having to do all of this work when coming up with your proposal you
didn’t explain any of it in your proposal, so committee members are redoing the work you have
already done because your proposal does not include any information about the problems you
found in other solutions, or the rationales for the trade offs your solution makes, etc.

Sending the short email without including all your work is resulting in more work for everyone,
including you.

—Oliver


> On Aug 3, 2025, at 12:19 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On Sunday, August 3, 2025, David Brown wrote:
>>>
>>
>> What use would that be? If the programmer knows that a pointer in the function might be a null pointer, and wants to throw if that is the case, then the programmer can write "if (!p) throw nullptr;", or whatever suits their needs.
>
>
> It would allow us to write one-liner functions like:
>
> unsigned GetCOMportNumber(char const *const p)
> {
> return stoul( strstr(p, "COM") + 3 );
> }
>
> and also to write a one-liner like:
>
> pInterface1->GetInterface2()->LastChild()->Release();
>
> instead of:
>
> if ( nullptr == pInterface1 ) return;
> auto p = pInterface1->GetInterface2();
> if ( nullptr == p ) return;
> auto p2 = p->LastChild();
> if ( nullptr == p2 ) return;
> p2->Release();
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals