[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.
https://reviews.llvm.org/D25710
More information about the llvm-commits
mailing list