djasper added a comment.

I still really believe that these config options do no make sense and are 
actively confusing.

I see two options:

- We leave this as is
- We fix this right

The right fix here is (IMO) that a style already is per language and thus 
already has a member specifying the language. What we have done in the scope of 
formatting the contents of raw string literals is that you can, in the same 
configuration file/setting, have different styles based on the language being 
formatted. Thus, if we encounter a text-formatted proto inside a C++ raw string 
literal, we switch to the style flags for proto rather than using those for 
C++. You have these different options in the same style configuration file, in 
a different section per language.

So, if you look at a config file, you could see how a user sets the existing 
IndentWrappedFunctionNames to true for ObjC and to false for C++. Now IMO, that 
should mean that ObjC function names are indented and C++ functions are not, 
even if the language of the *file* is ObjC. It doesn't require us to repeat 
these options for each language in the style for each language.

Getting this right will require some refactoring of how a style is passed 
around and used, but I think it'd be the right thing to do.

Look at it the other way. If we go forward with this patch you can have style 
configuration files saying:


  BasedOnStyle: LLVM
  Language: Cpp
  IndentWrappedObjCMethodNames: Never
  IndentWrappedFunctionNames: true
  Language: ObjC
  IndentWrappedObjCMethodNames: Always
  IndentWrappedFunctionNames: false

I find it very hard to explain what that even means.

  rC Clang

cfe-commits mailing list

Reply via email to