Idea for allowing "using namespace" in headers

[geza....@gmail.com]

Hi all,

Common wisdom is that we can use "using namespace" in .cpp files (sure, there are people who disagree with this), but we should not use it in header files.

The only safe solution I know which allows using directive in headers in a safe manner is this:

namespace MyLib {

namespace detail {

using namespace std;

void func() {
// use things from std here
}

}

using detail::func;

}

void userCode() {
MyLib::vector<int> a; // OK, this is not valid, symbols of "std" is not accessible here
}


So, "using namespace" is in a "detail" namespace, and afterwards we need to use using declarations to bring stuff from the "detail" namespace to "MyLib".

Now, as far as I know, the only reason to use a "detail" namespace in this case is to avoid "importing" everything from std into MyLib in a way that this importing is visible from outside (for users of MyLib).

So, If we don't use a detail namespace:

namespace MyLib {

using namespace std;

void func() {
// use things from std here
}

}

void userCode() {
MyLib::vector<int> a; // BAD, because this is valid, and we don't want it to be valid
}

So, in user code, using MyLib::vector valid, which is not we wanted, we don't want to pollute MyLib with symbols of std for the *users* of MyLib.

Now, what would happen, if we had a special "using namespace", which only "imports" symbols for code in the namespace it is put in? A "static using namespace":

namespace MyLib {

static using namespace std; // Note "static", that's the only difference

void func() {
// use things from std here
}

}

void userCode() {
MyLib::vector<int> a; // OK, this is not valid, because "using namespace std" is "static"
}

So, "static using namespace" would import symbols for MyLib only, and for user code (stuff outside MyLib) would not be affected by that.

What do you think about this idea? Is it reasonable? How big is the change to the standard?

Thanks,
Geza

[Mr Flibble]

It is an egregious idea (see Alf's pathological coding style). It is only
five key strokes to type "std::" and it makes it obvious when we are using
something from stdlib. Not using the "std::" prefix actually makes code
harder to grok.

There is nothing wrong with the following code, it is easy to read and
doesn't rely on context to know what a symbol means:

{
std::vector<int> v { 1, 7, 42 };
std::cout << v[2] << std::endl;
}

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That’s what I would say."

[Öö Tiib]

On Sunday, 2 September 2018 20:52:23 UTC+3, geza....@gmail.com wrote:
>
> What do you think about this idea? Is it reasonable? How big is the change
> to the standard?

I think that you need to start from reasons. Why most senior and expert level specialists dislike "using namespace std;" in header files? Why lot of
them dislike it even in cpp files?

Can you imagine where code bases use standard library? Is it really only
inside of implementation of "void func()"?

[geza....@gmail.com]

On Sunday, 2 September 2018 21:47:29 UTC+2, Öö Tiib wrote:
> On Sunday, 2 September 2018 20:52:23 UTC+3, geza....@gmail.com wrote:
> >
> > What do you think about this idea? Is it reasonable? How big is the change
> > to the standard?
>
> I think that you need to start from reasons.

The reason is simple: we can avoid to write "std::" in cpp files with "using namespace std;". With current techniques, we cannot avoid it in header files conveniently. With my idea, we could, if I'm not mistaken.

> Why most senior and expert level specialists dislike "using namespace std;" in header files?

Because with current techniques, we cannot use "using namespace std;" conveniently. But if we could, maybe these expert level specialists would use it in header files too. Or maybe they could tell, why my idea is wrong. But to be honest, I think it is a perfectly reasonable demand that we can avoid putting "std::" all over the place in header files (not just cpp files). There are a lot of cases, where this "std::" is just noise.

Note, I don't talk about "using namespace std" only. We can use it for other namespaces, not just "std". If my huge program uses "SuperDuperLibrary" all over the place, I'd like to able to use "using namespace SuperDuperLibrary;" in header files as well.

> Why lot of them dislike it even in cpp files?

And a lot of them says otherwise. For example: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-using

Please don't discuss this subject here. It is highly subjective. There are a lot of scenarios, where "using namespace std;" or other namespace is perfectly fine.

> Can you imagine where code bases use standard library? Is it really only
> inside of implementation of "void func()"?

Sorry, I don't understand what you mean here.

[Mr Flibble]

You say don't discuss it because it is highly subjective but it is
subjective as to whether the issue you are trying to address is actually a
problem in the first place.

[Öö Tiib]

On Sunday, 2 September 2018 23:09:12 UTC+3, geza....@gmail.com wrote:
> On Sunday, 2 September 2018 21:47:29 UTC+2, Öö Tiib wrote:
> > On Sunday, 2 September 2018 20:52:23 UTC+3, geza....@gmail.com wrote:
> > >
> > > What do you think about this idea? Is it reasonable? How big is the change
> > > to the standard?
> >
> > I think that you need to start from reasons.
>
> The reason is simple: we can avoid to write "std::" in cpp files with
> "using namespace std;". With current techniques, we cannot avoid it
> in header files conveniently. With my idea, we could, if I'm not
> mistaken.
>
> > Why most senior and expert level specialists dislike "using namespace std;" in header files?
>
> Because with current techniques, we cannot use "using namespace std;"
> conveniently. But if we could, maybe these expert level specialists
> would use it in header files too. Or maybe they could tell, why my
> idea is wrong. But to be honest, I think it is a perfectly reasonable
> demand that we can avoid putting "std::" all over the place in header
> files (not just cpp files). There are a lot of cases, where this
> "std::" is just noise.

You avoid answering. Why they started to dislike it? Why it was bad?
What it was that they experienced? What convinced them?

> Note, I don't talk about "using namespace std" only. We can use it for
> other namespaces, not just "std". If my huge program uses
> "SuperDuperLibrary" all over the place, I'd like to able to use
> "using namespace SuperDuperLibrary;" in header files as well.
>
> > Why lot of them dislike it even in cpp files?
>
> And a lot of them says otherwise. For example: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-using

Should I interpret that answer as "I do not know"? Ok I explain then.
One major event that convinced many was arrival of C++11. Several
large code bases used super-duper-library "boost" at side of "std".
Some added "using namespace std; using namespace boost;" in every cpp
file. Arrival of C++11 turned those code-bases into pile of hard to
repair junk.

>
> Please don't discuss this subject here. It is highly subjective. There
> are a lot of scenarios, where "using namespace std;" or other namespace
> is perfectly fine.

You do not want to even discuss the reasons why most expert level
specialists dislike "using namespace std;"? Then how you can dream of
removing these reasons?

> > Can you imagine where code bases use standard library? Is it really only
> > inside of implementation of "void func()"?
>
> Sorry, I don't understand what you mean here.

I also suspect that you do not understand what I ask. I several times
asked reasons that your fix supposedly removes and you say that "it
is highly subjective". Do you think that it is matter of taste like
whitespace usage e.g. do we write "if (x)" or "if(x)"?

[geza....@gmail.com]

On Sunday, 2 September 2018 22:58:57 UTC+2, Öö Tiib wrote:
> On Sunday, 2 September 2018 23:09:12 UTC+3, geza....@gmail.com wrote:
> > On Sunday, 2 September 2018 21:47:29 UTC+2, Öö Tiib wrote:
> > > On Sunday, 2 September 2018 20:52:23 UTC+3, geza....@gmail.com wrote:
> > > >
> > > > What do you think about this idea? Is it reasonable? How big is the change
> > > > to the standard?
> > >
> > > I think that you need to start from reasons.
> >
> > The reason is simple: we can avoid to write "std::" in cpp files with
> > "using namespace std;". With current techniques, we cannot avoid it
> > in header files conveniently. With my idea, we could, if I'm not
> > mistaken.
> >
> > > Why most senior and expert level specialists dislike "using namespace std;" in header files?
> >
> > Because with current techniques, we cannot use "using namespace std;"
> > conveniently. But if we could, maybe these expert level specialists
> > would use it in header files too. Or maybe they could tell, why my
> > idea is wrong. But to be honest, I think it is a perfectly reasonable
> > demand that we can avoid putting "std::" all over the place in header
> > files (not just cpp files). There are a lot of cases, where this
> > "std::" is just noise.
>
> You avoid answering. Why they started to dislike it? Why it was bad?
> What it was that they experienced? What convinced them?

Supposedly because it has a global effect. "using namespace" "leaked" from the header file into user code which uses the header file. Which is bad, of course, no doubt it. And maybe there are other reasons as well (you should tell, if you know any). But note, my idea doesn't have this "leak".

> > Note, I don't talk about "using namespace std" only. We can use it for
> > other namespaces, not just "std". If my huge program uses
> > "SuperDuperLibrary" all over the place, I'd like to able to use
> > "using namespace SuperDuperLibrary;" in header files as well.
> >
> > > Why lot of them dislike it even in cpp files?
> >
> > And a lot of them says otherwise. For example: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-using
>
> Should I interpret that answer as "I do not know"? Ok I explain then.
> One major event that convinced many was arrival of C++11. Several
> large code bases used super-duper-library "boost" at side of "std".
> Some added "using namespace std; using namespace boost;" in every cpp
> file. Arrival of C++11 turned those code-bases into pile of hard to
> repair junk.

Sure, there can be problems, if you are not careful. That doesn't make "using namespace" inherently bad. Have you read the link I put here?

> > Please don't discuss this subject here. It is highly subjective. There
> > are a lot of scenarios, where "using namespace std;" or other namespace
> > is perfectly fine.
>
> You do not want to even discuss the reasons why most expert level
> specialists dislike "using namespace std;"? Then how you can dream of
> removing these reasons?

I don't want to discuss it, because that's another discussion. And I repeat myself here: have you read the link I put here? I would consider Bjarne Stroustrup and Herb Sutter as expert level specialists. They don't dislike "using namespace std;".

> > > Can you imagine where code bases use standard library? Is it really only
> > > inside of implementation of "void func()"?
> >
> > Sorry, I don't understand what you mean here.
>
> I also suspect that you do not understand what I ask. I several times
> asked reasons that your fix supposedly removes and you say that "it
> is highly subjective". Do you think that it is matter of taste like
> whitespace usage e.g. do we write "if (x)" or "if(x)"?

You could explain instead what you meant here.

And I don't get this sentence either, what you mean here: "I several times asked reasons that your fix supposedly removes and ..."

[Paavo Helde]

On 2.09.2018 23:09, geza....@gmail.com wrote:
> On Sunday, 2 September 2018 21:47:29 UTC+2, Öö Tiib wrote:
>> On Sunday, 2 September 2018 20:52:23 UTC+3, geza....@gmail.com wrote:
>>>
>>> What do you think about this idea? Is it reasonable? How big is the change
>>> to the standard?
>>
>> I think that you need to start from reasons.
>
> The reason is simple: we can avoid to write "std::" in cpp files with "using namespace std;". With current techniques, we cannot avoid it in header files conveniently. With my idea, we could, if I'm not mistaken.

Well, we can avoid writing std::, but why should we? Losing a lot of
clarity for ... what? Saving 5 keystrokes?

In my code, there is no "using namespace std;" in either header or
source files. There are "using namespace ..." directives for some
tightly coupled neighbor projects though - which makes it even more wise
to avoid "using namespace std;", btw.

[Öö Tiib]

On Monday, 3 September 2018 00:15:58 UTC+3, geza....@gmail.com wrote:
> On Sunday, 2 September 2018 22:58:57 UTC+2, Öö Tiib wrote:
> > On Sunday, 2 September 2018 23:09:12 UTC+3, geza....@gmail.com wrote:

Snipping it a bit.

> > > Note, I don't talk about "using namespace std" only. We can use it for
> > > other namespaces, not just "std". If my huge program uses
> > > "SuperDuperLibrary" all over the place, I'd like to able to use
> > > "using namespace SuperDuperLibrary;" in header files as well.
> > >
> > > > Why lot of them dislike it even in cpp files?
> > >
> > > And a lot of them says otherwise. For example: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-using
> >
> > Should I interpret that answer as "I do not know"? Ok I explain then.
> > One major event that convinced many was arrival of C++11. Several
> > large code bases used super-duper-library "boost" at side of "std".
> > Some added "using namespace std; using namespace boost;" in every cpp
> > file. Arrival of C++11 turned those code-bases into pile of hard to
> > repair junk.
> Sure, there can be problems, if you are not careful. That doesn't make
> "using namespace" inherently bad. Have you read the link I put here?

How you suggest to be careful about what wasn't there when you wrote the
code years earlier?

The link:
"Here (obviously), the standard library is used pervasively and apparently
no other library is used, so requiring std:: everywhere could be
distracting."

OK, that is careful.

You:

"If my huge program uses "SuperDuperLibrary" all over the place, I'd like
to able to use "using namespace SuperDuperLibrary;" in header files as
well."

And that is not careful. I explained how that approach turned hundreds of
thousands of lines of code into junk.

It was because both standard library and super duper libraries evolve and
not being explicit what exactly you use from what library (when you use
several) can and eventually will result with an overload picked from
library that wasn't there when you wrote the code.

...

> And I repeat myself here: have you read the link I put here? I would
> consider Bjarne Stroustrup and Herb Sutter as expert level specialists.
> They don't dislike "using namespace std;".

You either did not read it yourself or you did not understand what it
said. How lot of different libraries most code bases use side-by-side?
Why to avoid reasons? Why to turn it into like-dislike and argument
from authority? Such arguments are fallacious.

[Juha Nieminen]

geza....@gmail.com wrote:
> Common wisdom is that we can use "using namespace" in .cpp files

The only situation where "using namespace" ought to be used is to bring the
contents of one namespace into another (and basically never to the global
namespace). And these situations ought to be quite rare.

"using namespace std;" should never be used, anywhere. In the extremely few
cases where there might be an argument for bringing a standard library name
into the current scope, only that one name should be done so, not the
entirety of the std namespace. (One example situation where you might want
to bring a standard library name into the current scope is if you are
writing a templated function that, for example, swaps two templated
elements, and you want to support for a custom swap function implementation,
for instance. Thus you would write "using std::swap;" inside that function
and then just "swap(a, b);" But even these situations ought to be rare.)

[Juha Nieminen]

geza....@gmail.com wrote:
> The reason is simple: we can avoid to write "std::" in cpp files with "using namespace std;".

Why would you want to avoid that?

[Alf P. Steinbach]

On 02.09.2018 23:55, Paavo Helde wrote:
> [snip]

> Well, we can avoid writing std::, but why should we? Losing a lot of
> clarity for ... what? Saving 5 keystrokes?

No, it's about reducing visual clutter and verbosity. Reducing that
improves local readability. And improved readability improves global
clarity, the ability to understand the main things at-a-glance.

Consider

auto d = std::distance(a, b)

The `std::` prefix tells you that you can look up the specification of
this function, which will tell you what it computes and the exact type
of `d`.

That /possibility of later clarity/ might, to some, associate with
direct clarity, compared to

auto d = distance(a, b)

... which involves a possibly user-defined function that you possibly
can't look up, e.g. possibly you don't even have the source code.

But there are just two main cases:

* You are unclear on what `distance` does or produces.
For clarity you will have to look up the function spec. In the case
where `distance` is the standard library's function neither style
helps you do that more easily. E.g. in Visual Studio, place the text
cursor on `distance` and hit F1, that's it, regardless of which style.

* You are clear on what `distance` does and produces.
Well.

So with the in-your-face clarity of what each individual statement
means, out of the picture, it boils down to: do the namespace prefixes
that introduce more text to read and visually distracting `::` symbols
all over, help readability?

For me the `::` symbols and namespace names just reduce readability,
greatly, and thereby reduce global clarity.

Some others, maybe that includes you, maintain that for them they do
help readability. I tend to not believe that claim but I don't entirely
dismiss it, because it /can/ conceivably be like a suitable amount of
the right kind of background music can help one focus on a task. I guess
the mechanism is by keeping the otherwise too active parts of the mind
occupied with the music, maybe.

So it seems possible that to some degree it's a subjective thing, but I
would be very surprised if Mother Nature has evolved people so that a
majority are helped in their thought processes by having `::` and
redundant namespace names peppered all over the text, as background.


Cheers!,

- Alf

[Paavo Helde]

On 3.09.2018 10:46, Alf P. Steinbach wrote:
> On 02.09.2018 23:55, Paavo Helde wrote:
>> [snip] Well, we can avoid writing std::, but why should we? Losing a
>> lot of clarity for ... what? Saving 5 keystrokes?
>
> No, it's about reducing visual clutter and verbosity. Reducing that
> improves local readability. And improved readability improves global
> clarity, the ability to understand the main things at-a-glance.
>
> Consider
>
> auto d = std::distance(a, b)
>
> The `std::` prefix tells you that you can look up the specification of
> this function, which will tell you what it computes and the exact type
> of `d`.
>
> That /possibility of later clarity/ might, to some, associate with
> direct clarity, compared to
>
> auto d = distance(a, b)
>
> ... which involves a possibly user-defined function that you possibly
> can't look up, e.g. possibly you don't even have the source code.

Yes, that's the point. I greatly prefer std::distance(), especially in
case of short lines and single usage like in your example. Especially if
it's in template code and some other 'distance' could be involved,
depending on the types.

>
> But there are just two main cases:
>
> * You are unclear on what `distance` does or produces.
> For clarity you will have to look up the function spec. In the case
> where `distance` is the standard library's function neither style
> helps you do that more easily. E.g. in Visual Studio, place the text
> cursor on `distance` and hit F1, that's it, regardless of which style.

So I need to perform a special operation in order to clarify something
which could have easily been written clearly in the first place.

And yes, if I'm looking at some foreign code or code written by myself
more than 3 months ago, I am always in doubt what it actually does. The
mere fact that I'm looking on it already means it is probably doing
something wrong. Anything which helps me to understand more clearly what
the code exactly does is greatly appreciated at that point.

And no, VS does not work nearly as reliably as you suggest (though it
has become better over years). And I don't always have the luxury to
work with an IDE, not to speak about one which can reliably look up symbols.

>
> * You are clear on what `distance` does and produces.
> Well.
>
> So with the in-your-face clarity of what each individual statement
> means, out of the picture, it boils down to: do the namespace prefixes
> that introduce more text to read and visually distracting `::` symbols
> all over, help readability?
>
> For me the `::` symbols and namespace names just reduce readability,
> greatly, and thereby reduce global clarity.
>
> Some others, maybe that includes you, maintain that for them they do
> help readability. I tend to not believe that claim but I don't entirely
> dismiss it, because it /can/ conceivably be like a suitable amount of
> the right kind of background music can help one focus on a task. I guess
> the mechanism is by keeping the otherwise too active parts of the mind
> occupied with the music, maybe.

Your beliefs do not change the reality ;-)

Anyway, I suspect that using or not using the std:: prefix usage has
mostly to do with habits. If I see std::max() and std::uint32_t all the
time in the code I get used to them and would feel lost without std::.
It looks like for you it is the opposite.

> So it seems possible that to some degree it's a subjective thing, but I
> would be very surprised if Mother Nature has evolved people so that a
> majority are helped in their thought processes by having `::` and
> redundant namespace names peppered all over the text, as background.

There is also the issue of namespace length. "std::" is short enough to
write out, some other namespaces not so, especially when used often.

There is also the issue of the codebase size and homogeneity. For
example I made a quick search of 'distance' in our codebase and
immediately found a 'double distance(double a, double b);' in a
third-party header.

[Vir Campestris]

On 03/09/2018 08:46, Alf P. Steinbach wrote:

<snip>

>
> Consider
>
>     auto d = std::distance(a, b)
>
> The `std::` prefix tells you that you can look up the specification of
> this function, which will tell you what it computes and the exact type
> of `d`.

</snip>

And this need to look up is where I differ from some of the eminences of
C++; I use auto only where I have to (type of a lambda, for instance).

Looking up the return type of std::distance I can see why you want to
avoid all that typing. But you type it once, and maintain the code for
years.

Andy

[woodb...@gmail.com]

On Sunday, September 2, 2018 at 2:47:29 PM UTC-5, Öö Tiib wrote:
> On Sunday, 2 September 2018 20:52:23 UTC+3, geza....@gmail.com wrote:
> >
> > What do you think about this idea? Is it reasonable? How big is the change
> > to the standard?
>
> I think that you need to start from reasons. Why most senior and expert level specialists dislike "using namespace std;" in header files? Why lot of
> them dislike it even in cpp files?

Not everyone uses cpp files. I use cc files.


Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards

[woodb...@gmail.com]

I don't know about the greatly part, but I tend to
agree. In my code I write:
using namespace ::cmw;

in source files in order to get a little bit of that.
I only permit that though for my namespaces.

>
> Some others, maybe that includes you, maintain that for them they do
> help readability. I tend to not believe that claim but I don't entirely
> dismiss it, because it /can/ conceivably be like a suitable amount of
> the right kind of background music can help one focus on a task. I guess
> the mechanism is by keeping the otherwise too active parts of the mind
> occupied with the music, maybe.
>
> So it seems possible that to some degree it's a subjective thing, but I
> would be very surprised if Mother Nature has evolved people so that a

Has anyone watched this?
https://duckduckgo.com/?q=%22edward+Feser%22+shapiro&t=ffab&ia=videos&iax=videos&iai=9FvYwpyFbIQ

> majority are helped in their thought processes by having `::` and
> redundant namespace names peppered all over the text, as background.
>
>
> Cheers!,
>
> - Alf

Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Jorgen Grahn]

On Mon, 2018-09-03, Alf P. Steinbach wrote:
...

> For me the `::` symbols and namespace names just reduce readability,
> greatly, and thereby reduce global clarity.
>
> Some others, maybe that includes you, maintain that for them they do
> help readability. I tend to not believe that claim but I don't entirely
> dismiss it, because it /can/ conceivably be like a suitable amount of
> the right kind of background music can help one focus on a task. I guess
> the mechanism is by keeping the otherwise too active parts of the mind
> occupied with the music, maybe.
>
> So it seems possible that to some degree it's a subjective thing, but I
> would be very surprised if Mother Nature has evolved people so that a
> majority are helped in their thought processes by having `::` and
> redundant namespace names peppered all over the text, as background.

You're either joking, or you greatly underestimate how differently
people read and think about code.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> No, it's about reducing visual clutter and verbosity. Reducing that
> improves local readability. And improved readability improves global
> clarity, the ability to understand the main things at-a-glance.

Once, in another forum, I made the argument that using the std:: prefix
increases readability, rather than reduce it. Someone tried to prove me
wrong by posting a piece of code with half a dozen lines, and about a
dozen uses of standard library names.

Quite ironically, at least personally, I found the version *with* the
std:: prefixes to be easier to understand and read than the version
where they were removed.

For some reason which I can't really understand, some people seem to
think that if "std::" appears many times in the code, that somehow
makes it "cluttered" and "less readable". For reasons unknown.

To me that's as silly as saying that using capital letters at the
beginning of sentences makes the text "cluttered" and "less readable".

[Fred.Zwarts]

"Paavo Helde" schreef in bericht news:pmje0m$ot7$1...@dont-email.me...

>
>On 3.09.2018 10:46, Alf P. Steinbach wrote:
>> On 02.09.2018 23:55, Paavo Helde wrote:
>>> [snip] Well, we can avoid writing std::, but why should we? Losing a
>>> lot of clarity for ... what? Saving 5 keystrokes?
>>
>> No, it's about reducing visual clutter and verbosity. Reducing that
>> improves local readability. And improved readability improves global
>> clarity, the ability to understand the main things at-a-glance.
>>
>> Consider
>>
>> auto d = std::distance(a, b)
>>
>> The `std::` prefix tells you that you can look up the specification of
>> this function, which will tell you what it computes and the exact type
>> of `d`.
>>
>> That /possibility of later clarity/ might, to some, associate with
>> direct clarity, compared to
>>
>> auto d = distance(a, b)
>>
>> ... which involves a possibly user-defined function that you possibly
>> can't look up, e.g. possibly you don't even have the source code.
>
>Yes, that's the point. I greatly prefer std::distance(), especially in case
>of short lines and single usage like in your example. Especially if it's in
>template code and some other 'distance' could be involved, depending on the
>types.

I understand your point. But it is not to only one to be considered. When I
look at code, I sometimes wonder why a particular header is included. When
the use of std:: is scattered al over the source file and I do not know all
symbols that are defined in the header, it is often difficult to find the
reason. Therefore, at the top of my code after the list of #includes, I
always have another list (often in a namespace) where I mention all symbols
imported from these headers, in a way that it easy to see which symbol is
from which header. That makes it easy to see why a certain header is
included and where a certain name comes from.

E.g.,

If I see that <iterator> is included, I need to know that distance is
defined there in order to understand why it is included in your example.
I find it much clearer if "#include <iterator>" is followed by "using
std::distance;".

Of course the imported symbols can also be named in a comment, but when the
code changes and other symbols are added, with the first method the compiler
will help me to update the list of imported symbols, but with these names in
a comment, the compiler cannot help.

Which of the two points is the most important is a personal taste, I think.

[Marcel Mueller]

Am 02.09.2018 um 19:52 schrieb geza....@gmail.com:
> Now, what would happen, if we had a special "using namespace", which only "imports" symbols for code in the namespace it is put in? A "static using namespace":
>
> namespace MyLib {
>
> static using namespace std; // Note "static", that's the only difference

[...]

> So, "static using namespace" would import symbols for MyLib only, and for user code (stuff outside MyLib) would not be affected by that.

I find this feature useful. But "static" is /highly/ misleading. This is
used to import static functions of a class into a namespace in other
languages.
The keyword "private" is more appropriate here. This behavior would be
similar to a using directive in a class.

Basically I would recommend to allow "private:" and "public:" within a
namespace in general. Then there is no more need for the "::detail" work
around.
Furthermore this puts namespaces and static classes (with only static
members) closer together. From my point of view there is no need for a
difference of these two syntax elements at all. It should be just like
"class" versus "struct". The defaults should differ. And well, instance
members should not be allowed in namespaces. So namespace is basically
just a class that contains only types and static members. And of course,
it is never complete, so multiple definitions of the same namespace are
still allowed.
Maybe we should also allow inheritance of namespaces. The effect is
basically the same than a using directive in the first line, but this
would put "protected:" also into a meaningful semantic.

From this point the next step might be to allow extension methods like
in C#. The only difference that I /strongly/ recommend is that the
required using directive should include the name of the defining static
class and not elapse its name like in C# and import all extension
methods of all classes in a namespace at once. Since in C++ you would
use "namespace" for extension methods rather than "static class" the
latter is straight forward.

> What do you think about this idea? Is it reasonable?

From my point of view yes. Although purists dislike using namespace,
prefixing everything with "std::" can significantly blow up the code
with impact on readability and maintainability. Especially when it
appears a dozen time in a line, e.g. in case of nested template types,
binder functions etc.

> How big is the change to the standard?

I think it's a moderate change.


Marcel

[Tim Rentsch]

I don't want to be pulled into this debate, but there is a point
about Alf's comment that I think deserves clarifying. What he
said is he would be surprised "if Mother Nature has evolved
people so that ...". I read his comments as saying he accepts,
at least provisionally, that different people perceive the
relative readability (of the two cases) differently. What he
doubts is that such reactions are innate behavior, as opposed to
learned behavior. A good example is the direction of writing.
I find it very much easier to read text that is written left-to-
right, as opposed to right-to-left. Some other people are
exactly the opposite of that. Surely though most of that is
learned behavior rather than innate behavior: if I had grown
up learning to read right-to-left that would seem natural to me,
and reading left-to-right would seem strange and difficult. Is
the same true for using, or not using, std:: everywhere? I
think it's hard to make a convincing argument that a preference
either way is innate behavior more than it is learned behavior.
Of course, it still might be true, but I don't see any compelling
reason why it should be true. And if it is learned behavior,
then clearly different people may reasonably have different
views on the relative readabilities of the two approaches.

[Tim Rentsch]

Juha Nieminen <nos...@thanks.invalid> writes:

> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>
>> No, it's about reducing visual clutter and verbosity. Reducing that
>> improves local readability. And improved readability improves global
>> clarity, the ability to understand the main things at-a-glance.
>
> Once, in another forum, I made the argument that using the std:: prefix
> increases readability, rather than reduce it.

Do you mean you gave reasons explaining your view, or simply
stated your impression as an assertion (perhaps phrased as some
sort of circular reasoning)?

> Someone tried to prove me
> wrong by posting a piece of code with half a dozen lines, and about a
> dozen uses of standard library names.
>
> Quite ironically, at least personally, I found the version *with* the
> std:: prefixes to be easier to understand and read than the version
> where they were removed.
>
> For some reason which I can't really understand, some people seem to
> think that if "std::" appears many times in the code, that somehow
> makes it "cluttered" and "less readable". For reasons unknown.

Oftentimes the reasons are unknown even to the people themselves.
A large part of the challenge in such discussions is trying to
draw out people on the other side of the fence, to see if it is
possible to understand why they think what they think. And vice
versa, which paradoxically often becomes harder the more strongly
a preference is held.

> To me that's as silly as saying that using capital letters at the
> beginning of sentences makes the text "cluttered" and "less readable".

Your view may seem just as silly to them. I don't always agree
with Alf's views of things but I think most here would agree he
makes an effort to be a thoughtful guy. If your views and his
views on this choice are pretty much diametrically opposed, which
it kind of looks like they are, what might be done to resolve, or
at least understand, the underlying reaons for those differences?