Re: operator new/delete forwarding

[Howard Hinnant <hhinnant at apple dot com>]

On Apr 30, 2007, at 8:14 PM, Martin Sebor wrote:

> Howard Hinnant wrote:
> > On Jul 26, 2006, Howard Hinnant wrote:
> > (http://gcc.gnu.org/ml/libstdc++/2006-07/msg00157.html)
> > > On Jul 25, 2006, at 8:35 PM, Gabriel Dos Reis wrote:
> > >
> > > > OK, you guys have changed my mind and convinced me we should  
> > > > proceed
> > > > as Martin suggests.
> > > > We'll meet at Portalnd and rubber-stamp Howard's suggestion if LWG
> > > > feels OK :-)
> > > > Howard, you know the Master of LWG issue list, right? :-)
> > >
> > > I'll interpret that as a request to reopen lwg 206. Consider it  
> > > done:
> > >
> > > <note>
> > > Reopened due to a gcc conversation between Howard, Martin and  
> > > Gaby. Forwarding
> > > or not is visible behavior to the client and it would be useful  
> > > for the client
> > > to know which behavior it could depend on.
> > > </note>
> > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#206
> > was voted into the C++0X working draft on Friday April 20, 2007.
>
> I must have been asleep when we discussed this issue in Oxford.
> The Rationale in the issue on your home page:
> http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg- 
> defects.html#206
> still says that "[the operators] may become unlinked, and that
> is by design. If a user replaces one, the user should also
> replace the other." Doesn't the resolution go against that design?
> If it does, what was the rationale for the change? And how did we
> address Robert's compatibility concern? (Sorry to be asking these
> questions now instead of when we talked about it.)

The issue was discussed in Batavia in January, and listed in  
Tentatively Ready status at that point.  All of the issues from  
Batavia were given visibility on the std-lib reflector on Jan 25 in  
message c++std-lib-17919.  The Batavia issues were again highlighted  
in the pre-Oxford mailing paper:

   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2183.html

I agree we are moving at a frightening pace.  But it is my impression  
that this pace is required to meet o 2009 deadline.

Yes, the resolution goes against the design that the no-throw and  
throwing signatures become unlinked.  N2158 explains why the former  
design is fragile and leads to client code crashing (providing  
rationale for the change).

Robert expressed concern publicly in the Batavia meeting, and later  
to me privately.  So I noted his concern in the issue (indeed I value  
his opinion highly).  However there was no further concern or  
objection noted between N2183 (pre-Oxford mailing Mar 9), and the  
full committee vote on this issue Apr 20.

The Batavia issues were reviewed in Oxford on the morning of Tuesday,  
Apr 17, however the LWG was split between doing this and meeting with  
the EWG concerning threading issues (I attended the latter, and do  
not know who attended which).  The part of the LWG that was reviewing  
the Batavia issues Ok'd transitioning 206 from Tentatively Ready to  
Ready (Ready for end of the week vote).

Robert's concerns were noted in Batavia but overruled by straw poll  
at that time.  At no time since the Batavia meeting were concerns  
raised or straw polls asked for to the best of my knowledge.  And  
repeated visibility was given to this issue, as well as several other  
controversial issues, in preparation for the Oxford meeting.  -- It's  
a busy time right now with lots of critical/controversial decisions  
being made.

-Howard