On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor <mse...@gmail.com> wrote:
> On 02/13/2018 07:47 AM, Jason Merrill wrote:
>> On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor <mse...@gmail.com> wrote:
>>> I really don't think it's helpful to try to force noreturn
>>> to match between the primary and its specializations.
>> I continue to disagree.
> Can you explain what use case you are concerned about that isn't
> already handled by the warning about noreturn function returning?

A specialization that forgot [[noreturn]] and therefore doesn't get
the desired warning.

> For reference, the cases I consider important are:
> 1) "Unimplemented" primary template declared noreturn that throws
>    or exits but whose specializations return a useful value and
>    make use of attribute malloc (or one of the other blacklisted
>    attributes).
> 2) The converse of (1).  A primary that returns a useful malloc
>    like value and some of whose specializations are not/cannot
>    be meaningfully implemented and are declared noreturn.

Right, but I still disagree with this use of noreturn, and therefore
don't consider these cases important.

> Defining template specializations that differ from the primary
> template in their implementation is idiomatic (analogous to
> defining overloads or overridden virtual functions).

> In any event, I am mainly interested in fixing the two bugs
> (one a P1 regression).   If you consider changing the warning
> aspect of the patch a condition of accepting the fix please let
> me know.  Removing the noreturn keyword from the whitelist is
> trivial.

Please do.


Reply via email to