I would like to add a minor feature to C++1y: "using static namespace".
It would have exactly the semantics of "using namespace", except:

  (1) It would be non-transitive; it would point to the given namespace
for lookup purposes, but not copy the given namespace into the enclosing
namespace.

  (2) If the given namespace was involved in name lookup, then any
lookup that resulted in a set of names both in and out of the target
namespace would be a fatal error.  In other words, no ambiguity (actual
or potential) could result.

Given these limitations, it seems like an easy proposal to include, as
it is orthogonal with all other proposed changes.  We could go back to
writing "string" instead of "std::string" a thousand times a day.

What say?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_3412_7323021.1368502865217
Content-Type: text/plain; charset=ISO-8859-1



On Monday, May 13, 2013 6:52:09 PM UTC-7, Chip Salzenberg wrote:
>
> I would like to add a minor feature to C++1y: "using static namespace".
> It would have exactly the semantics of "using namespace", except:
>
>   (1) It would be non-transitive; it would point to the given namespace
> for lookup purposes, but not copy the given namespace into the enclosing
> namespace.
>
>   (2) If the given namespace was involved in name lookup, then any
> lookup that resulted in a set of names both in and out of the target
> namespace would be a fatal error.  In other words, no ambiguity (actual
> or potential) could result.
>
> Given these limitations, it seems like an easy proposal to include, as
> it is orthogonal with all other proposed changes.  We could go back to
> writing "string" instead of "std::string" a thousand times a day.
>
> What say?
>

I say that this is *not* a "minor change". It *sounds* minor to say, but
specifying #1 would require a significant reworking of the standard
language.

`using namespace` doesn't "copy the given namespace". It's *all* done via
"lookup purposes". If you say `using namespace std`, the standard says that
unqualified attempts to look things up in the current namespace will also
look through the `std` namespace for them too. It doesn't say that
everything in `std` is "copied" into the current namespace.

`std::cout` will not become a member of the global namespace by doing
`using namespace std`. It will simply become accessible through the global
namespace via unqualified lookups in that namespace.

So your proposal wants to create a distinction that does not and cannot
exist.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3412_7323021.1368502865217
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, May 13, 2013 6:52:09 PM UTC-7, Chip Salzenberg wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">I would like to add a minor featu=
re to C++1y: "using static namespace".=20
<br>It would have exactly the semantics of "using namespace", except:
<br>
<br>&nbsp; (1) It would be non-transitive; it would point to the given name=
space
<br>for lookup purposes, but not copy the given namespace into the enclosin=
g
<br>namespace.
<br>
<br>&nbsp; (2) If the given namespace was involved in name lookup, then any
<br>lookup that resulted in a set of names both in and out of the target
<br>namespace would be a fatal error. &nbsp;In other words, no ambiguity (a=
ctual
<br>or potential) could result.
<br>
<br>Given these limitations, it seems like an easy proposal to include, as
<br>it is orthogonal with all other proposed changes. &nbsp;We could go bac=
k to
<br>writing "string" instead of "std::string" a thousand times a day.
<br>
<br>What say?
<br></blockquote><div>&nbsp;<br>I say that this is <b>not</b> a "minor chan=
ge". It <i>sounds</i> minor to say, but specifying #1 would require a signi=
ficant reworking of the standard language.<br><br>`using namespace` doesn't=
 "copy the given namespace". It's <i>all</i> done via "lookup purposes". If=
 you say `using namespace std`, the standard says that unqualified attempts=
 to look things up in the current namespace will also look through the `std=
` namespace for them too. It doesn't say that everything in `std` is "copie=
d" into the current namespace.<br><br>`std::cout` will not become a member =
of the global namespace by doing `using namespace std`. It will simply beco=
me accessible through the global namespace via unqualified lookups in that =
namespace.<br><br>So your proposal wants to create a distinction that does =
not and cannot exist.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3412_7323021.1368502865217--

.

------=_Part_3862_8978829.1368558726530
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, May 14, 2013 4:41:05 AM UTC+1, Nicol Bolas wrote:
>
>
>
> On Monday, May 13, 2013 6:52:09 PM UTC-7, Chip Salzenberg wrote:
>>
>> I would like to add a minor feature to C++1y: "using static namespace".
>> It would have exactly the semantics of "using namespace", except:
>>
>>   (1) It would be non-transitive; it would point to the given namespace
>> for lookup purposes, but not copy the given namespace into the enclosing
>> namespace.
>>
>>   (2) If the given namespace was involved in name lookup, then any
>> lookup that resulted in a set of names both in and out of the target
>> namespace would be a fatal error.  In other words, no ambiguity (actual
>> or potential) could result.
>>
>> Given these limitations, it seems like an easy proposal to include, as
>> it is orthogonal with all other proposed changes.  We could go back to
>> writing "string" instead of "std::string" a thousand times a day.
>>
>> What say?
>>
>
> I say that this is *not* a "minor change". It *sounds* minor to say, but
> specifying #1 would require a significant reworking of the standard
> language.
>

And semantics.  Any proposal like this needs to go into *great* detail
about how it interacts with ADL, and how it solves (or doesn't solve) all
the issues described in the various "Fixing ADL" proposals over the past
10+ years.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3862_8978829.1368558726530
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, May 14, 2013 4:41:05 AM UTC+1, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><br><br>On Monday, May 13, 2013 6:52=
:09 PM UTC-7, Chip Salzenberg wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>I would like to add a minor feature to C++1y: "using static namespace".=20
<br>It would have exactly the semantics of "using namespace", except:
<br>
<br>&nbsp; (1) It would be non-transitive; it would point to the given name=
space
<br>for lookup purposes, but not copy the given namespace into the enclosin=
g
<br>namespace.
<br>
<br>&nbsp; (2) If the given namespace was involved in name lookup, then any
<br>lookup that resulted in a set of names both in and out of the target
<br>namespace would be a fatal error. &nbsp;In other words, no ambiguity (a=
ctual
<br>or potential) could result.
<br>
<br>Given these limitations, it seems like an easy proposal to include, as
<br>it is orthogonal with all other proposed changes. &nbsp;We could go bac=
k to
<br>writing "string" instead of "std::string" a thousand times a day.
<br>
<br>What say?
<br></blockquote><div>&nbsp;<br>I say that this is <b>not</b> a "minor chan=
ge". It <i>sounds</i> minor to say, but specifying #1 would require a signi=
ficant reworking of the standard language.<br></div></blockquote><div><br>A=
nd semantics.&nbsp; Any proposal like this needs to go into *great* detail =
about how it interacts with ADL, and how it solves (or doesn't solve) all t=
he issues described in the various "Fixing ADL" proposals over the past 10+=
 years.</div><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3862_8978829.1368558726530--

.