On May 19, 4:38 pm, vandevoo...@gmail.com wrote:
> On May 17, 11:50 pm, Michael Kilburn <crusader.m...@gmail.com> wrote:
> > I am sure everyone here like the idea of changing core language
> > feature... ;-) But has anyone ever considered getting rid or better
> > replacing 'Koenig lookup'?
>
> I don't think you'll see change in this area for the C++0x time frame.

I am sure I won't see this change in the timeframe of my life. :-) But
it is interesting to keep trying...

> However, you may be interested in N1691 (Dave Abrahams' "explicit
> namespace" proposal) and Herb Sutter's N2103 (a proposal to limit ADL
> in some ways).

Thanks! Do you by any chance know the status of these proposals? Are
they closed?

I read both of them and in my (modest) opinion they should not be
implemented -- they fail to address the root of the problem (i.e. ADL
itself).

ADL is a complex and evil and should not be 'fixed' by adding more
complexity to it (Herb's proposal), also I do not see any benefit from
adding yet another mechanism (explicit namespaces) while retaining ADL
(Dave's proposal) -- in this case additional complexity would be
interaction between those mechanisms. I'd very much prefer getting rid
of ADL completely and replace with with simple and straightforward
mechanism of 'global' namespace (which is nothing but an extension of
existing 'namespace' mechanism)

Ah, and btw -- I re-read my original posting, it is full of cr%p --
you probably want to skip most of 'philosophical' stuff and look
directly into the proposed idea. :-)

Michael.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 25, 3:25 pm, Michael Kilburn <crusader.m...@gmail.com> wrote:
> I'd very much prefer getting rid
> of ADL completely and replace with with simple and straightforward
> mechanism of 'global' namespace (which is nothing but an extension of
> existing 'namespace' mechanism)

Are you being cute by suggesting the global namespace is a new
concept, or are you referring to the current global namespace?

IMHO, I believe the current system would be quite sufficient without
ADL at all.

For example (pseudo code)

//1 - with ADL
namespace std
{   istream& operator<< (istream& , int );
     class istream
     {
     public:
         friend istream& operator<< (istream& , int );
       //...
     };
     istream& operator<< (istream& , int ) { /* ... */ }
}

//2 - without ADL
namespace std { class istream; }
std::istream& operator<< (std::istream& , int );
namespace std
{   class istream
     {
     public:
         friend istream& operator<< (istream& , int );
       //...
     };
}
std::istream& operator<< (std::istream& , int ) { /* ... */ }

//
I don't see how case 1 with ADL has (sufficiently enough) different
functionality than case 2 without ADL. In case one, a user of an
istream object can use operator<< without qualifying it or using
declaration / using directive it because it is found through ADL. In
case 2, a user of istream can use operator<< without qualifying it or
using declaration / using directive it because the function is in the
global namespace, and thus in scope.

It's not really polluting the global namespace. Under the old scheme
with ADL, one cannot make a function ::operator<<(std::istream& ,
int ) and call it without explicitly qualifying the call because ADL
will find the other function and you'll get an ambiguous call. Under
scheme 2 without ADL putting the c++ std lib function operator<< in
the global namespace, the user also cannot simply define ::operator<<
(std::istream& , int ) because it would be a duplicate definition. The
global cannot be "accidentally" called any more than the ADL version
can be "accidentally" called.

Put another way, I fail to see any real difference between namespace
member functions with namespace member type parameters vs global
functions with a namespace member type parameter. They're effectively
equivalent (barring the not useful case of in ADL defining a function
in the global namespace with the same signature as the namespace
member function. It's not useful because you cannot call either
function without qualifying it, and thus there's no real reason to
create such a function in the global namespace with the same
signature.)

It's probably too late to fix this now as too much code depends on it,
but ideally ADL should never have existed, and those functions which
we wanted to be found through ADL should have just been declared and
defined in the global namespace. (That is, assuming the goals of ADL
are worthwhile. Alternatively, we could have not had ADL and put all
those functions in the namespace, and require the user to using
declaration / using directive them. However, if you're calling a
function with a namespace member type as an argument, I like that the
function from that library is found without using declaration / using
directive that function as currently done with ADL or as could be done
without ADL if those functions were just global namespace members.)

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 26, 12:43 pm, joshuamaur...@gmail.com wrote:
> On May 25, 3:25 pm, Michael Kilburn <crusader.m...@gmail.com> wrote:
> > I'd very much prefer getting rid
> > of ADL completely and replace with with simple and straightforward
> > mechanism of 'global' namespace (which is nothing but an extension of
> > existing 'namespace' mechanism)
>
> Are you being cute by suggesting the global namespace is a new
> concept, or are you referring to the current global namespace?

I am being cute...


> IMHO, I believe the current system would be quite sufficient without
> ADL at all.
>
> [skipped a lot]
>
> Put another way, I fail to see any real difference between namespace
> member functions with namespace member type parameters vs global
> functions with a namespace member type parameter. They're effectively
> equivalent (barring the not useful case of in ADL defining a function
> in the global namespace with the same signature as the namespace
> member function. It's not useful because you cannot call either
> function without qualifying it, and thus there's no real reason to
> create such a function in the global namespace with the same
> signature.)

I am kind of agree with you... Here are my thoughts:

Why we need ADL?:
- having function fun(Type v) we would like it to behave
polymorphically (wrt arguments's type) -- but this is something that
function overloading already does
- we also would like to specify given type's overload of func() in the
same spot where Type is defined... If Type is defined in a particular
namespace -- we'd like to define it there. But then overloading won't
work.

Essentially, 'global' namespace allows overloading of a function from
inside a different namespace:

namespace global {
   void func(int) {...}
}

namespace ns {
class Type {};

void func(Type) { ... } // this will overload global::func()
}

ns::Type t;
func(t); // will call ns::func()


namespace another {

void foo()
{
      ns::Type t;
      func(t); // will call ns::func()
}

}


Alternatively 'global' namespace can be replaced by a special
devclaration that will mark given function name as 'special' wrt
overloading, e.g.:

declspec(global_overloading) func;

whenever compiler encounters function named 'func' after this
declaration -- it will know that this is an attempt to overload
(globally reserved) function.


> It's probably too late to fix this now as too much code depends on it,

I have a feeling that ADL can be replaced with 'global' namespace
almost transparently (but of course, I am probably missing smth very
obvious)


> but ideally ADL should never have existed, and those functions which
> we wanted to be found through ADL should have just been declared and
> defined in the global namespace. (That is, assuming the goals of ADL
> are worthwhile. Alternatively, we could have not had ADL and put all
> those functions in the namespace, and require the user to using
> declaration / using directive them. However, if you're calling a
> function with a namespace member type as an argument, I like that the
> function from that library is found without using declaration / using
> directive that function as currently done with ADL or as could be done
> without ADL if those functions were just global namespace members.)

Well, this is what happens with my 'global' namespace, isn't it?

Michael.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi,

I am sure everyone here like the idea of changing core language
feature... ;-) But has anyone ever considered getting rid or better
replacing 'Koenig lookup'? Personally I never liked it and consider it
a hack, another type of static polymorphism that conflicts with
existing mechanisms and produces problems:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1440.htm (see
issue #226 and related)

Philosophy behind my reasoning could be shortly explained as:
- function name is a key to a semantic (obviously, that is why we give
them meaningful names) and (via static polymorphism) to specific
functionality (based on argument types and current scope of visibility
(SoV))
- 'namespace' concept is a way to separate different semantics that
are referred using the same name
- but Koenig lookup hacks/breaks this idea by effectively reserving
function name regardless of current scope for the same semantic

This obviously was done for a reason, e.g. you would normally expect
the same semantic for operator+() regardless of scope. Therefore that
thing that might replace Koenig lookup should be some kind of
mechanism that will allow to reserve function name on a global level
(and leave static polymorphism to function overloading) -- as an
additional bonus it will simplify related chapters in C++
standard. ;-)
It does not really matter right now how this mechanism might look
like. E.g. it could be something like this:
- magic namespace (e.g. 'global')
- where you are going to put all names that should have the same
semantic regardless of current SoV
- which will behave similar to unnamed namespace (will merge with
current SoV)
- therefore when container wants to provide implementation for swap
function -- all it needs is:
class Container { ... };
namespace global { void swap(Container& l, Container& r) { l.swap
(r); } }

Of course various things (like nested namespaces have to be addressed
properly and convenient things like allowing 'global' to designate the
same namespace regardless of current nesting level) will have to be
addressed before this idea will be mature enough...

What do you think?

Michael.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 17, 11:50 pm, Michael Kilburn <crusader.m...@gmail.com> wrote:
> Hi,
>
> I am sure everyone here like the idea of changing core language
> feature... ;-) But has anyone ever considered getting rid or better
> replacing 'Koenig lookup'? Personally I never liked it and consider it
> a hack, another type of static polymorphism that conflicts with
> existing mechanisms and produces problems:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1440.htm(see
> issue #226 and related)
>
> Philosophy behind my reasoning could be shortly explained as:
> - function name is a key to a semantic (obviously, that is why we give
> them meaningful names) and (via static polymorphism) to specific
> functionality (based on argument types and current scope of visibility
> (SoV))
> - 'namespace' concept is a way to separate different semantics that
> are referred using the same name
> - but Koenig lookup hacks/breaks this idea by effectively reserving
> function name regardless of current scope for the same semantic
>
> This obviously was done for a reason, e.g. you would normally expect
> the same semantic for operator+() regardless of scope. Therefore that
> thing that might replace Koenig lookup should be some kind of
> mechanism that will allow to reserve function name on a global level
> (and leave static polymorphism to function overloading) -- as an
> additional bonus it will simplify related chapters in C++
> standard. ;-)
> It does not really matter right now how this mechanism might look
> like. E.g. it could be something like this:
> - magic namespace (e.g. 'global')
> - where you are going to put all names that should have the same
> semantic regardless of current SoV
> - which will behave similar to unnamed namespace (will merge with
> current SoV)
> - therefore when container wants to provide implementation for swap
> function -- all it needs is:
> class Container { ... };
> namespace global { void swap(Container& l, Container& r) { l.swap
> (r); } }
>
> Of course various things (like nested namespaces have to be addressed
> properly and convenient things like allowing 'global' to designate the
> same namespace regardless of current nesting level) will have to be
> addressed before this idea will be mature enough...
>
> What do you think?


I don't think you'll see change in this area for the C++0x time frame.

However, you may be interested in N1691 (Dave Abrahams' "explicit
namespace" proposal) and Herb Sutter's N2103 (a proposal to limit ADL
in some ways).

       Daveed


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]