Sorry, I wasn’t able to follow all the logic in the style guideline and the
email message nor fully understand what the script enforces. So I’ll give my
view on this and hope it helps.
- The rule against "using namespace xxx" in headers in namespace scope exists
because of the notion that someone might be building software that depends on a
header without being able to modify the header. Combining the namespace may
create name conflicts that are not fixable.
The assumption that clients are using a header and can’t modify it may not in
fact be true for headers inside WebKit. Most are designed for use only within
WebKit and so in theory that guideline could be limited only to headers
intended for use outside WebKit. On the other hand, I have the impression that
on some platforms such as Qt it is common for clients to directly use internal
headers, such as the ones in WebCore.
I can’t think of a concrete example where a "using xxx::yyy" would be a problem
inside a class or function scope in a header, so it seems fine to permit those.
I suppose there’s a chance that "using namespace xxx" could still cause a
problem even inside a function, but again it’s hard for me to think of a real
example.
- Inside non-header files, there is the guideline of preferring "using
namespace std" to "using std::min". This suggestion comes from me.
It does not seem worthwhile to maintain a list of "using" statements at the top
of the file mentioning each imported identifier. In theory we could avoid some
rare conflicts this way, but in practice it just seems like a lot of unhelpful
bookkeeping.
At first, I did the "using std::min" thing, but now I prefer "using namespace
std" inside implementation files, and I suggest we retain that guideline.
I also don’t see a need for "using" statements of either kind further down in
the file. It seems they can go at the top, right after the includes. But maybe
I’ve missed some useful case.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
