[PATCH] D25710: [Doc] Drop MSVC2013 support

Chandler Carruth via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 19 00:56:19 PDT 2016

chandlerc added a comment.


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.
mehdi_amini wrote:
> 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.
I have no idea what the motivation here was...

I am very happy with non-static class member initializers *if and only if the equals is used*.

I have fairly strong objections to using braced initialization *syntax* here. But that is just about the syntax, which this comment doesn't really mention. I would just change this to say something along the lines of:

  * Feel free to use these wherever they make sense and where the `=`
    syntax is allowed. Don't use braced initialization syntax.

(and link that last bit however the links work in RST)


More information about the llvm-commits mailing list