Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Sam <sam@email-scan.com>
Newsgroups: comp.lang.c++
Subject: Re: We have a new standard!
Date: Fri, 03 Jan 2025 11:53:11 -0500
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <cone.1735923191.159097.297354.1000@ripper.email-scan.com>
References: <cone.1735849245.346442.281052.1000@ripper.email-scan.com> <vl8m0u$3t4v1$1@dont-email.me> <cone.1735909901.753978.294757.1000@ripper.email-scan.com> <vl8sfi$3u4fh$1@dont-email.me> <cone.1735919451.379621.297354.1000@ripper.email-scan.com> <vl9243$3vkvl$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 03 Jan 2025 17:53:14 +0100 (CET)
Injection-Info: dont-email.me; posting-host="438ddabde0aa42590c2ac3552678e1fb";
	logging-data="5224"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/kKAnXeRSRoGThvAsJ9EMP"
Cancel-Lock: sha1:rqr0989GdPpdx9Tt+ByarUt/jaE=
X-Mailer: https://www.courier-mta.org/cone/
X-Shameless-Plug: https://github.com/svarshavchik
Content-Disposition: inline
Bytes: 4023

Muttley@DastardlyHQ.org writes:

> On Fri, 03 Jan 2025 10:50:51 -0500
> Sam <sam@email-scan.com> wibbled:
> >Paavo Helde writes:
> >Here's a free clue. Define "function X throws exception Y" if it throws that
> >exception (and it doesn't catch it itself), or if it calls function Z that's
> >declared (in Z's throw specifier) as throwing that exception. The compiler
> >has all the information needed to know which exception can be thrown out of
> >that function.
> >
> >This is not C. This is C++. The compiler has the signature of every function
> >called by code.
>
> It needs more than that when function pointers are involved. It cannot

Do you happen to recall how a function pointer indicates that it's pointing  
to a noexcept function, by any chance?

Newflash: this already exists in C++. But instead of noexcept you put down  
the throw specification, and it works the same way.

> necessarily know at compile time which function will be assigned to the
> pointer so how is it supposed to know if the exception sig is valid?

The same way the compiler already prohibits you from assigning a pointer to  
a throwing function to a pointer to a noexcept function.

Am I the only one around here who doesn't see this as rocket science?

=========================================================================
int (*noexcept_func)() noexcept;

int (*except_func)();

void foo()
{
	except_func=noexcept_func; // OK
	noexcept_func=except_func; // Error
}
=========================================================================

A full throw specifier can also be validated for correctness, in the same  
exact FUCKING way, at compile time. This would look like…

=========================================================================
int (*noexcept_func)() throw(ExceptionA);

int (*except_func)() throw(ExceptionA, ExceptionB);

void foo()
{
	except_func=noexcept_func; // OK
	noexcept_func=except_func; // Error
}
=========================================================================

Sheesh, dark magic, isn't it?

(add a few more rules dealing how subclasses and superclasses are compared,  
in the throw specifier, for completeness)

> Unless
> you're suggesting also have an exception sig for function pointers which  
> would
> probably break a whole load of code and make life difficult for zero gain.

Not any more than existing code had to be rewritten when throw exceptions  
were removed leaving behind just noexcept.

For all that talk about not breaking existing code, it sure got broken many  
times, in C++'s history. If someone with a brain actually does a Picard, and  
makes it so, backwards compatibility won't be much of a concern.