Dear Walter:

Although it's not mentioned in N3515,

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3515.pdf

I think the following try is supposed to work:

namespace foo {
  using nice_t = public int;
  void f(nice_t) {}
}

foo::nice_t a = 10;
f(a);

What do you think?

BTW, I'd like to see you in this "Future Proposals" mailing list :)

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_112_30529720.1359839965895
Content-Type: text/plain; charset=ISO-8859-1

On Friday, February 1, 2013 3:02:14 PM UTC-8, Zhihao Yuan wrote:
>
> Dear Walter:
>
> Although it's not mentioned in N3515,
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3515.pdf
>
> I think the following try is supposed to work:
>
> namespace foo {
>   using nice_t = public int;
>   void f(nice_t) {}
> }
>
> foo::nice_t a = 10;
> f(a);
>
> What do you think?
>

I don't think the proposal needs to explicitly mention this. By virtue of
the fact that it is creating a new, separate type (which acts in virtually
all ways as a complete clone of the original, and therefore is unrelated to
it), it should act no differently from this:

namespace foo{
  class nice_t {};
  void f(nice_t) {}
}

foo::nice_t a;
f(a);

I don't think the proposal needs explicit language to make that work. But
I'm not a spec-lawyer, so I can't be sure.

--

---
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_112_30529720.1359839965895
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, February 1, 2013 3:02:14 PM UTC-8, Zhihao Yuan wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">Dear Walter:
<br>
<br>Although it's not mentioned in N3515,
<br>
<br><a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n351=
5.pdf" target=3D"_blank">http://www.open-std.org/JTC1/<wbr>SC22/WG21/docs/p=
apers/2013/<wbr>n3515.pdf</a>
<br>
<br>I think the following try is supposed to work:
<br>
<br>namespace foo {
<br>&nbsp; using nice_t =3D public int;
<br>&nbsp; void f(nice_t) {}
<br>}
<br>
<br>foo::nice_t a =3D 10;
<br>f(a);
<br>
<br>What do you think?<br></blockquote><div><br>I don't think the proposal =
needs to explicitly mention this. By virtue of the fact that it is creating=
 a new, separate type (which acts in virtually all ways as a complete clone=
 of the original, and therefore is unrelated to it), it should act no diffe=
rently from this:<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">namespace</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">cl=
ass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> nice_t=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">nice_t</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{}</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> <br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>&=
nbsp;<br>foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">nice_t=
 a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>I don't think =
the proposal needs explicit language to make that work. But I'm not a spec-=
lawyer, so I can't be sure.<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_112_30529720.1359839965895--

.

On Sat, Feb 2, 2013 at 3:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I don't think the proposal needs explicit language to make that work. But
> I'm not a spec-lawyer, so I can't be sure.

The problem is not that obvious.  Consider this: What is the
namespace associated with an opaque typedef (3.4.2/2)?

  namespace A {
    struct A {};
    void f(A) {}
  }

  namespace B {
    using B = public A::A;
  }

  B b;
  f(b);  // ???

If B::B's associated namespace is A, like a normal typedef,
then A::f is called since B is implicitly converted to A; if A::A
is some type without an associated namespace, like `int`,
then ADL works no where.  I guess this is Walter's intention.

But now I suggest this:  B::B is associated with B, thus A::A's
ADL APIs under A no longer work.  Then we can write those
APIs under B by forwarding them to those under A, or rewrite
our new versions.  So that we don't need the whole new syntax

  using B = public A::A {
    // forwarding
  };

to do this, and we can enable ADL on fundamental types
by opaquely typedef them.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_940_10301388.1360121429470
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, February 5, 2013 6:45:36 PM UTC-8, Zhihao Yuan wrote:
>
> On Sat, Feb 2, 2013 at 3:19 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > I don't think the proposal needs explicit language to make that work.
> But
> > I'm not a spec-lawyer, so I can't be sure.
>
> The problem is not that obvious.  Consider this: What is the
> namespace associated with an opaque typedef (3.4.2/2)?
>
>   namespace A {
>     struct A {};
>     void f(A) {}
>   }
>
>   namespace B {
>     using B = public A::A;
>   }
>
>   B b;
>   f(b);  // ???
>
> If B::B's associated namespace is A, like a normal typedef,
> then A::f is called since B is implicitly converted to A; if A::A
> is some type without an associated namespace, like `int`,
> then ADL works no where.  I guess this is Walter's intention.
>

How do you figure that? B is in no way related to A. It is implicitly *
convertible* to A, but that's not the same thing. It's no different than
this:

namespace NA
{
  struct A{};
  void f(A) {}
}

namespace NB
{
  struct B{ operator NA::A() {return NA::A();} };
}

int main()
{
   NB::B b;
   f(b);
   return 0;
}

By the rules of C++, this *must* fail. The associated namespace of `NB::B`
is just `NB`.

When the proposal says "introduce a new type", that's what it means. Not an
alias, not a variation, a *new type*. That's what an opaque typedef is; a
new type which is in almost all ways distinct from the original, yet
maintains the interface of the original. For classes, it is the equivalent
of copying the class definition to the new location and renaming it. With a
few small alterations based on the public/private/protected association.


>
> But now I suggest this:  B::B is associated with B, thus A::A's
> ADL APIs under A no longer work.  Then we can write those
> APIs under B by forwarding them to those under A, or rewrite
> our new versions.  So that we don't need the whole new syntax
>
>   using B = public A::A {
>     // forwarding
>   };
>
> to do this, and we can enable ADL on fundamental types
> by opaquely typedef them.
>

You do need such a syntax for certain operators which only work as member
functions. operator+=, for example. Granted, I'm not particularly happy
with having to write definitions for operators just to get sensible
defaults (ie: being able to use math operators for private opaque typedefs.
There should be some shorthand syntax that says, "give me the obvious
implementations for these operators".

--

---
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_940_10301388.1360121429470
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, February 5, 2013 6:45:36 PM UTC-8, Zhihao Yuan wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Feb 2, 2013 at 3:19 PM, =
Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"SRZbarGtZPIJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; I don't think the proposal needs explicit language to make that wo=
rk. But
<br>&gt; I'm not a spec-lawyer, so I can't be sure.
<br>
<br>The problem is not that obvious. &nbsp;Consider this: What is the
<br>namespace associated with an opaque typedef (3.4.2/2)?
<br>
<br>&nbsp; namespace A {
<br>&nbsp; &nbsp; struct A {};
<br>&nbsp; &nbsp; void f(A) {}
<br>&nbsp; }
<br>
<br>&nbsp; namespace B {
<br>&nbsp; &nbsp; using B =3D public A::A;
<br>&nbsp; }
<br>
<br>&nbsp; B b;
<br>&nbsp; f(b); &nbsp;// ???
<br>
<br>If B::B's associated namespace is A, like a normal typedef,
<br>then A::f is called since B is implicitly converted to A; if A::A
<br>is some type without an associated namespace, like `int`,
<br>then ADL works no where. &nbsp;I guess this is Walter's intention.<br><=
/blockquote><div><br>How do you figure that? B is in no way related to A. I=
t is implicitly <i>convertible</i> to A, but that's not the same thing. It'=
s no different than this:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">namespace</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> NA<br></span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">A</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{}</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">namespace=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> NB<br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> NA</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> NA</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">A</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp;NB</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">B b</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp;f</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
; &nbsp;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">re=
turn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>By the rules o=
f C++, this <i>must</i> fail. The associated namespace of `NB::B` is just `=
NB`.<br><br>When the proposal says "introduce a new type", that's what it m=
eans. Not an alias, not a variation, a <i>new type</i>. That's what an opaq=
ue typedef is; a new type which is in almost all ways distinct from the ori=
ginal, yet maintains the interface of the original. For classes, it is the =
equivalent of copying the class definition to the new location and renaming=
 it. With a few small alterations based on the public/private/protected ass=
ociation.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>But now I suggest this: &nbsp;B::B is associated with B, thus A::A's
<br>ADL APIs under A no longer work. &nbsp;Then we can write those
<br>APIs under B by forwarding them to those under A, or rewrite
<br>our new versions. &nbsp;So that we don't need the whole new syntax
<br>
<br>&nbsp; using B =3D public A::A {
<br>&nbsp; &nbsp; // forwarding
<br>&nbsp; };
<br>
<br>to do this, and we can enable ADL on fundamental types
<br>by opaquely typedef them.<br></blockquote><div><br>You do need such a s=
yntax for certain operators which only work as member functions. operator+=
=3D, for example. Granted, I'm not particularly happy with having to write =
definitions for operators just to get sensible defaults (ie: being able to =
use math operators for private opaque typedefs. There should be some shorth=
and syntax that says, "give me the obvious implementations for these operat=
ors".</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_940_10301388.1360121429470--

.

On Tue, Feb 5, 2013 at 9:30 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> That's what an opaque typedef is; a new
> type which is in almost all ways distinct from the original, yet maintains
> the interface of the original.

As I pointed out, these two behaviors can't be achieved at
the same time.  You can copy the definition of a class, but how to
deal with the ADL interfaces separated into multiple files?  One
way is to leave the new type's associated namespace
unchanged, the other is to discard all original ADL interfaces.
The latter one is what I suggested (and what your conceptual
implementation implied).


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_722_9033639.1360127832556
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, February 5, 2013 8:12:34 PM UTC-8, Zhihao Yuan wrote:
>
> On Tue, Feb 5, 2013 at 9:30 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > That's what an opaque typedef is; a new
> > type which is in almost all ways distinct from the original, yet
> maintains
> > the interface of the original.
>
> As I pointed out, these two behaviors can't be achieved at
> the same time.  You can copy the definition of a class, but how to
> deal with the ADL interfaces separated into multiple files?


That's the subject of a separate proposal<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Xqp0Bprv3gw>.
Also, using ADL for simple free functions like that is somewhat... dubious.


>  One
> way is to leave the new type's associated namespace
> unchanged,


But it wouldn't be a "new type", would it?


> the other is to discard all original ADL interfaces.
> The latter one is what I suggested (and what your conceptual
> implementation implied).
>

--

---
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_722_9033639.1360127832556
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, February 5, 2013 8:12:34 PM UTC-8, Zhihao Yuan wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Tue, Feb 5, 2013 at 9:30 PM, Nicol Bo=
las &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
HikIucHiNW0J">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; That's what an opaque typedef is; a new
<br>&gt; type which is in almost all ways distinct from the original, yet m=
aintains
<br>&gt; the interface of the original.
<br>
<br>As I pointed out, these two behaviors can't be achieved at
<br>the same time. &nbsp;You can copy the definition of a class, but how to
<br>deal with the ADL interfaces separated into multiple files?</blockquote=
><div><br>That's the subject of <a href=3D"https://groups.google.com/a/isoc=
pp.org/forum/#!topic/std-proposals/Xqp0Bprv3gw">a separate proposal</a>. Al=
so, using ADL for simple free functions like that is somewhat... dubious.<b=
r>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> &nbsp;One
<br>way is to leave the new type's associated namespace
<br>unchanged,</blockquote><div><br>But it wouldn't be a "new type", would =
it?<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> the other =
is to discard all original ADL interfaces.
<br>The latter one is what I suggested (and what your conceptual
<br>implementation implied).<br></blockquote>

<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_722_9033639.1360127832556--

.