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?
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.
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.
Martin
