Hi Jason, Sorry I haven't been able to get back to this. I've been swamped with other work, and we haven't had the resources to properly address this. Jeff Chapman will be working on cleaning this up for when master/trunk re-opens.
> I find the proposed always_continue semantics kind of nonsensical, as > somewhat evidenced by the contortions the implementation gets into with > marking the violation handler as pure. The trick of assigning the > result to a local variable won't work with optimization. We tend to agree and think it's practically non-implementable. IIRC, later contracts proposals steered away from adding this as a concrete semantic. I suspect killing this would be fine. > > +/* Definitions for C++ contract levels > > + Copyright (C) 1987-2018 Free Software Foundation, Inc. > > Should just be 2019 for a new file. Probably 2020 now :) > > + Contributed by Michael Tiemann (tiem...@cygnus.com) > > This seems inaccurate. :) Indeed :) > This change to member function redeclaration seems undesirable; your > rationale in P1680 is "for generality", but member functions are already > stricter about redeclaration than non-member functions; I don't see a > reason to relax this rule just for contracts. With member functions, > there *is* always a canonical first declaration, and people expect the > class definition to have its complete interface, of which contracts are > a part. There was a proposal that gave more motivation than just "for generality". Apparently, I was a co-author -- I think I just helped write the wording. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1320r2.html > For non-member functions, we still need to complain if contracts are > added after we've seen an ODR-use of the function, just like with > explicit specializations. We could do that, but it doesn't seem necessary with this model. Whether the contracts have been seen or not doesn't affect which function is called. > > + /* TODO is there any way to relax this requirement? */ > > + if (DECL_VIRTUAL_P (olddecl) && !TYPE_BEING_DEFINED (DECL_CONTEXT > > (olddecl))) > > Relatedly, I don't think we want to relax this requirement. Probably. Virtual functions and contracts have complex interactions. There are going to be more EWG papers about this, I'm sure. > > + /* FIXME Is this right for friends? Can a friend refer to a static > > member? > > + Can a friend's contracts refer to our privates? Turning them into > > + [[assert]]s inside the body of the friend itself certainly lets them > > do > > + so. */ > > P0542 says contracts are limited to the accessibility of the function > itself, so a friend cannot refer to private members. That will almost certainly be changed. This was the proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1289r0.pdf There was near-unanimous support for removing that (19 for, 1 against). Andrew
