[cfe-commits] r148675 - in /cfe/trunk: lib/Sema/SemaDeclCXX.cpp test/SemaCXX/microsoft-cxx0x.cpp

[Douglas Gregor]

Sent from my iPhone

On Jan 24, 2012, at 1:12 PM, Sebastian Redl <sebastian.redl at getdesigned.at> wrote:

> 
> On 24.01.2012, at 19:35, Douglas Gregor wrote:
> 
>> 
>> On Jan 22, 2012, at 7:19 PM, Nico Weber wrote:
>> 
>>> Author: nico
>>> Date: Sun Jan 22 21:19:29 2012
>>> New Revision: 148675
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=148675&view=rev
>>> Log:
>>> In ms mode, a move assignment operator shouldn't mark a copy ctor as deleted.
>>> 
>>> MSVC2010's pair class has a move assignment operator but no explicit copy
>>> constructor, which makes it unusable without this change.
>>> 
>>> For symmetry, let move copy constructors not mark the default assignment
>>> operator as deleted either. Both changes match cl.exe's behavior.  Fixes
>>> pr11826.
>>> 
>>> Also update the standard excerpt to point to the right paragraph.
>> 
>> 
>> I'm not at all convinced that we should mimic this behavior of MSVC 2010. They implemented an older, pre-standard version of rvalue references. By emulating this behavior, we're prolonging the pain that goes along with having multiple, different implementations of this feature and making rvalue references ever harder than they are. 
>> 
>> Especially given that it looks like the next MSVC will fix their rvalue references support, per
>> 
>>    http://stackoverflow.com/questions/7421825/c11-features-in-visual-studio-11
>> 
>> I think we should revert this change (and it's MicrosoftMode follow-on) and mark the original PR as WONTFIX. 
>> 
>> Opinions?
> 
> Disagree. The stackoverflow answer takes its information from this blog post:
> 
> http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
> 
> There you can find that "rvalue references 2.1" are just a tiny fix compared to the VS2010 support ("2.0") regarding string literals. "3.0", i.e. automatic move generation (and thus probably the modern "rule of 5" rules) are explicitly stated to be unavailable in VS 11.

Ugh. 

> So we're stuck with this behavior at least until VS 11 SP 1 (signs indicate that some interim updated might contain an updated compiler supporting variadic templates), more likely until VS 12, so this sad state of affairs will persist in the MS STL headers for many years to come.

That's really unfortunate, but I agree. We can keep this compatibility hack unless Microsoft gets their act together. 

Sadness.