[lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Pavel Labath via lldb-dev]

On 08/10/2019 02:45, Larry D'Anna via lldb-dev wrote:
> Pavel Labath said
> 
>> some llvm classes, are so well-known and widely used, that qualifying
>> them with "llvm::" serves no useful purpose and only adds visual noise.
>> I'm thinking here mainly of ADT classes like String/ArrayRef,
>> Optional/Error, etc. I propose we stop explicitly qualifying these classes.
>>
>> We can implement this proposal the same way as clang solved the same
>> problem, which is by creating a special LLVM.h
>> <https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/LLVM.h>
>> header in the Utility library. This header would adopt these classes
>> into the lldb_private namespace via a series of forward and "using"
>> declarations.
>>
>> I think clang's LLVM.h is contains a well-balanced collection of adopted
>> classes, and it should cover the most widely-used classes in lldb too,
>> so I propose we use that as a starting point.
> 
> I think this is a great idea, particularly for llvm::Expected.   The signatures of functions
> using Expected arer kind of noisy already, and adding llvm:: doesn’t help.
> 
> Anyone object to this idea?

I am in still in favour of that. :) I consider the following points to 
be the benefits of this proposal:
- consistency with llvm/clang/lld
- the extra llvm:: qualifications make people want to do away with the 
"cruft" via "auto", which *decreases* consistency with llvm 
<http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>
- better formatting of code in the 80 columns we have available

On 08/10/2019 10:14, Jan Kratochvil wrote:
 > If I should say something I would keep llvm::.
 >
 > My reason: The LLVM types are in many cases emulating classes adopted
 > in future C++ standards and I find more clear llvm:: vs. std:: than
 > "" vs. std::. Moreover when std:: is commonly omitted in other projects.


Which classes do you have in mind exactly? I know a lot of llvm 
*functions* mimic similar std:: versions, but I can't think of any 
*classes* right now. I mean StringRef is similar to std::string_view and 
so, but they still differ in the spelling of the base name...

Also, I am not proposing importing any llvm functions this way (and in 
fact, I am against a blanket "using namespace llvm", even in c++ files, 
save for some files with heavy llvm ties). It is true that often these 
llvm functions can be accessed unqualified thanks to ADL, but this 
proposal has nothing to do with that.

pl