On Oct 11, 2011, at 3:49 PM, Rafael Ávila de Espíndola wrote: >> Note that there *is* a subtyping relationship here: a normal >> function can be safely used as a returns_twice function (which simply >> never actually returns twice). But that's useless. >> >> I agree that abstractly this ought to be a type attribute, and I >> don't think it would be difficult to take advantage of the current >> 'noreturn conversion' hooks to make the (unsafe) implicit conversion >> work, but I'm not sure there's any real value to adding this >> complexity. > > OK, so I think the consensus is > > * The hard coded list will be removed after 3.0 branches and dragonegg > producing this attribute too. > * The attribute should be part of the type > * We should try to avoid allowing unsafe conversions like > > int (*fptr)(jmp_buf) = &setjmp; > > but a returns_twice function pointer can point to a function with an > otherwise matching type.
Sorry; re-reading myself, I can see how this is a plausible interpretation, but this is actually not what I meant. Let me rephrase. I think that, divorced from any other considerations, returns_twice would belong in the type system. However, doing so would introduce significant complexity for basically zero value — if nothing else, the use restrictions on these functions make it extremely unlikely that they will ever be called indirectly. Therefore I think it should stay a decl attribute, and we can consider whether to make it a type attribute in the off-chance that we ever see a compelling use case. Note that even the template-metaprogramming use case will work correctly with decl attributes. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
