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

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&gt;
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?

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&gt;
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. :slight_smile: 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&gt;
- better formatting of code in the 80 columns we have available

> 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

llvm::StringRef vs. std::string, llvm::Optional vs. std::optional.

I do not want to argue whether it is ambiguous or not but you asked for an
+1/-1 opinion.

Jan