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. Jason
