Submitted slightly modified patch as r239600. Thanks!
http://reviews.llvm.org/D10410
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/l
int *f(); // no braces, irrelevant
int *f() { // space before the brace
auto f() { // space before the brace
auto f() -> int { // space before the brace
auto f() -> int * { // space before the brace
On Fri, Jun 12, 2015 at 1:16 AM Daniel Jasper wrote:
> Ok. To be clear, I don't care strongly
Ok. To be clear, I don't care strongly at all. If the two of you are convinced
this is better, lets just put it in.
How does this relate to "int *f();"? Do we simply not care about that
consistency at this point as this is about spacing out braces?
http://reviews.llvm.org/D10410
EMAIL PREFERE
In all of these cases, the cause of the spacing is not the {. We put spaces
on both sides of a multiply, or after a comma.
The debug thing is (IMO) a bad example in every way. It's a macro, the
contents are a block, and yuck.
On Fri, Jun 12, 2015 at 1:00 AM Daniel Jasper wrote:
> Those examples
Those examples are very selective, though:
someFunction(a, {1, 2, 3});
Debug({ llvm::errs() << "abc\n"; });
SomeIntType b = a * {7};
http://reviews.llvm.org/D10410
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_
I think we should do this, and I'll try to give a plausibly principled
rationale.
We have two uses of {}s that I care about: braced init lists and blocks. For
braced init lists, we routinely omit padding spaces around the {}s:
foo({x, y z});
return {{1, 2, 3}};
On the other hand, with ever
I am not actually sure here. The pro is that it doesn't really belong with the
"{". The con is that it looks a lot more like a multiplication. Not so
important for "int", but as soon as you have something where you aren't exactly
sure that it is a type, this can get confusing.
Also, there is th
