<div dir="ltr">I'd have no objection to individual .cpp files having a few using declarations for the specific types that file cares about:<div><br></div><div>    ...<br></div><div>    #include "llvm/ADT/ArrayRef.h"<br></div><div>    #include "llvm/ADT/Optional.h"</div><div>    ...</div><div><br></div><div>    using llvm::ArrayRef;</div><div>    using llvm::Optional;</div><div><br></div><div>And then the rest of the file uses the unqualified `ArrayRef` and `Optional`.  If it's just a few commonly used types, this get the improvements in typability and readability that you're looking for.</div><div><br></div><div>But keeps the aliasing local to the implementation file, which reduces the risks of conflicts and helps newbies understand where these types come from.</div><div><br></div><div>It also avoids the headaches of forward declarations.</div><div><br></div><div>LLDB has only a couple using declarations like this right now, but other parts of LLVM seem to do this more liberally.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 7:31 AM Pavel Labath <<a href="mailto:pavel@labath.sk">pavel@labath.sk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for the replies. I was hoping to get more positive feedback for <br>
this, so given the current mixed-feelings replies, I think I'll just <br>
give up on this idea, unless a more vocal supporter appears (probably <br>
not the best idea to send this out just before the easter holidays).<br>
<br>
In the mean time, here are my thoughts on what was said.<br>
<br>
<br>
On 18/04/2019 01:54, Adrian McCarthy wrote:<br>
> I don't have a strong opinion, but I lean against the idea for two reasons:<br>
> <br>
> 1.  The `llvm::` prefixes don't really hinder readability for me.  <br>
> They're like `std::` prefixes on all the C++ standard library types, <br>
> which I'm perfectly happy to type and read--moreso than using <br>
> declarations.  Sure, anybody who's been here a while knows which classes <br>
> come from LLVM, but new folks might build that knowledge by seeing the <br>
> prefixes.<br>
<br>
Yeah, I was wondering why I'm bothered by typing "llvm::" and not by <br>
"std::". I concluded that this is down to two things:<br>
1. we don't use that many things from the std:: namespace actually. <br>
Pretty much everything except std::string and std::vector is discouraged <br>
because llvm has better alternatives<br>
<br>
2. llvm names are longer. This is not just due to to "llvm" prefix, <br>
which is just one char, but also the class names themselves tend to be <br>
longer. std::vector vs llvm::SmallVector, std::map vs. llvm::DenseMap, <br>
std::string vs. llvm::StringRef, etc.<br>
<br>
This effect gets multiplied once you start to combine things. For <br>
instance if you have a function returning Expected<ArrayRef<T>> (which <br>
is not an unreasonable thing to do), then by the time you spell out the <br>
full type, more than half of your usable horizontal space is gone. <br>
Because of this, I've found myself using "auto" or relying on ADL more <br>
and more often, which I don't consider very ideal either.<br>
<br>
I don't think using "auto" is always a good choice because it hides <br>
interesting details. E.g. an Optional<T> can look a lot like <br>
Expected<T>, but there are differences in how they are supposed used <br>
which should not be overlooked (I wish I was able to type <br>
"Expected<auto>" :P). And ADL is sometimes just too magical...<br>
<br>
<br>
> <br>
> 2.  I'm not a fan of forward declaring types provided by other parts of <br>
> the code, as it requires intimate knowledge of implementation details.  <br>
> In practice this may not matter much for the types we're considering.  <br>
> If it grew more widespread, however, I'd be more concerned.  (Somewhere <br>
> I've written a long explanation of this opinion.  I'll go search for it <br>
> if anyone cares.  The Google style guide discourages forward <br>
> declarations, but the rationale given there isn't as persuasive.)<br>
<br>
Yeah, I agree the forward declarations are not ideal (and the clang file <br>
did raise my eyebrows when I first saw it), but after a while I started <br>
to like it.<br>
<br>
FWIW, I wouldn't be opposed to just #including the relevant files <br>
instead of forward-declaring stuff, but I think doing it the same way is <br>
better for consistency.<br>
<br>
<br>
Out of interest, I took a look at what lld is doing. I've found that <br>
while it doesn't have a LLVM.h equivalent, it is a heavy user of "using <br>
namespace llvm" (about 2 out of 3 cpp files have it). This approach <br>
wouldn't work that well for us because of naming conflicts ("Module"), <br>
and I would consider it inferior for the same reason that "using <br>
namespace std" is discouraged -- it just brings in too much stuff into <br>
your scope.<br>
<br>
regards,<br>
pl<br>
</blockquote></div>