[PATCH] D25710: [Doc] Drop MSVC2013 support

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 18 10:36:43 PDT 2016

mehdi_amini added inline comments.

Comment at: docs/CodingStandards.rst:136
     uninitialized. Non-scalar members generally have appropriate default
-    constructors, and MSVC 2013 has problems when braced initializer lists are
-    involved.
+    constructors.
kparzysz wrote:
> Prazek wrote:
> > jlebar wrote:
> > > mehdi_amini wrote:
> > > > jlebar wrote:
> > > > > Can we add a comment or something to the effect of "should we reconsider this now that msvc 2013 is gone?"
> > > > Maybe we should consider it now?
> > > For my part, I have no problem with braced initializers inside a class.  They can be helpful.  But where possible I prefer using an equals sign, `int foo_member = 42`, because that's just easier to understand.
> > > 
> > > I dunno if that's contentious, though.
> > I also prefer = everywhere.
> If MSVC was the only reason that braced initializers were disallowed then we should allow them now.  Why keep that restriction after MSVC is upgraded?
Note: the braced initializers policy is described somewhere else: http://llvm.org/docs/CodingStandards.html#do-not-use-braced-initializer-lists-to-call-a-constructor

I guess it is loosely related to the issue above, but not that much. My understanding is that the rule above forbid:
class X {
  std::string Name = "<uninitialized>";

I don't know the motivation for it though.


More information about the llvm-commits mailing list