FWIW, I don't approve of making contracts part of the function type -- and have said so in unambiguous terms at the last (Oulu) meeting.
On Wed, Oct 12, 2016 at 2:35 PM, David Vandevoorde <dav...@edg.com> wrote: > > On Oct 12, 2016, at 4:51 PM, John McCall <rjmcc...@apple.com> wrote: > > […] > > I'll admit that I don't attend committee meetings, but I thought that > implementation experience was expected *prior* to standardization, not > something that gets done months after voting the thing in concurrently with > the committee finalizing the language in a draft for next year's release. > > > That’s cute ;-) > > > You will note that I have omitted the necessary specializations for >>> "transaction_safe", as well as the incredibly common extension of >>> specialized calling conventions. >>> >>> This also breaks source compatibility for template matching, and >>> basically every function template in the standard library is going to >>> change manglings (and become *much* larger) due to noexcept expressions now >>> being mangled. >>> >> >> It's a problem, but I don't think it's as bad as you claim. The mangling >> of a function still wouldn't include its exception specification; this >> would only affect mangling in cases where a parameter or return type or >> template argument involves a function type with an exception-specification >> -- a lot less common than every function template in the standard library, >> but this still does change manglings for existing code. >> >> >> Okay, so it only triggers SFINAE failures in nested function types, and >> you can't overload templates by it? I agree that that helps a lot. >> >> And the entire proposal seems to have forgotten about >>> reference-to-function types. >>> >> >> The change to [dcl.init.ref]p4 allows a reference to non-noexcept >> function to bind to a noexcept function, and this indirectly allows the >> same during overload resolution, casts, and so on. What additional >> considerations were missed? >> >> >> I hadn't realized that the expression logic was so consistent about >> defining e.g. the behavior of the conditional operator on l-values in terms >> of reference binding. I apologize. >> >> ...I see that this adds a new special case to exception handling. >> > > Yes; I'd forgotten to mention this side of the ABI change. > > We'll also need a new flag on type_info objects to model this. In line > with the transaction_safe changes that Jason proposed, I suggest adding a > __noexcept_mask = 0x40 to __pbase_type_info, and representing a pointer to > noexcept function as a pointer with __noexcept_mask bit set to the > corresponding *non-noexcept* function pointer type. > > > I strongly disagree; we should take this opportunity to revisit that > decision. The floodgates are open, and this set of function type > attributes is clearly going to grow over time. (It's actually > transaction_safe that really drives this point home; noexcept is at least a > longstanding part of the core language in various forms.) We also have a > lot of vendor-specific function type attributes that are part of the type > but just aren't standardized and can't be represented in type_info. I > don't think it makes sense to indefinitely keep hacking these things into > the pointer type flags; we should just bite the bullet and create a new > function_type_info subclass. > > > I agree with you (John). > > (That said, I’ll keep resisting adding standard bifurcations to function > types. “contracts” and one alternative for coroutines are currently trying > to add to that list.) > > Daveed > > > _______________________________________________ > cxx-abi-dev mailing list > cxx-abi-dev@codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > >
_______________________________________________ cxx-abi-dev mailing list cxx-abi-dev@codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev