Thinking about ADL

[grigor...@gmail.com]

The most severe problem with argument-dependent lookup is that most of C++ programmers even experienced ones have no idea what it is.

On the other hand it allows operators to work as expected by most programmers and also allows to connect free functions to class.

So, I guess the consensus is that ADL has to be fixed by no-one knows how to fix it right.

 

A recent proposal by Dave Abrahams N3490 is written from a perspective of a library author. He argues that is sufficient to provide facility to explicitly disable ADL by

 

using = delete;

 

And then explicitly  enable ADL for some of functions expected to be found via ADL by

 

using swap;

 

The solution might be acceptable for library code but I do not think that it would work for user code.

First of all, in order to disable ADL users have to be aware of ADL. Second adding  'using = delete;' will break even hello world program

 

#include <iostream>
using = delete;

int main()
{
    std::cout << "Hello, world!" << std::endl; // operator << is not found 
    return 0;
}

Do we expect users to write 'using' for every operator?

 

Third is that there's useful idea that non-member functions should be preferred over member functions in class design.

Having ADL for free functions that form a part of public interface of a class is actually a good thing.

 

My idea is that it's not the user of a function has to decide whether it should be found by ADL, it's the author of a class.

For example, we could declare such functions with operator keyword. It is expected for operators to be found by ADL anyway.

 

template<typename T>

void operator swap(T& first, T& second);

 

Going further, we may allow to call operator functions as member functions. Then, there would be no need of notion of pure ADL, used for range-based for loop.

 

I know that there a lot of subtle details that should be figured out. And that's limiting ADL only to set of specially declared functions is a big change and should be done in stages.

But if we are going to fix ADL, then my understanding is that it should be fixed in this direction.

 

Regards,

Gregory

 

 

 

 

 

 

 

 

 

 

[Daniel Krügler]

2012/11/10 <grigor...@gmail.com>

The most severe problem with argument-dependent lookup is that most of C++ programmers even experienced ones have no idea what it is.

On the other hand it allows operators to work as expected by most programmers and also allows to connect free functions to class.

So, I guess the consensus is that ADL has to be fixed by no-one knows how to fix it right.

 

A recent proposal by Dave Abrahams N3490 is written from a perspective of a library author. He argues that is sufficient to provide facility to explicitly disable ADL by

 

using = delete;

 

And then explicitly  enable ADL for some of functions expected to be found via ADL by

 

using swap;

 

The solution might be acceptable for library code but I do not think that it would work for user code.

First of all, in order to disable ADL users have to be aware of ADL. Second adding  'using = delete;' will break even hello world program

 

#include <iostream>
using = delete;

int main()
{
    std::cout << "Hello, world!" << std::endl; // operator << is not found 
    return 0;
}

Do we expect users to write 'using' for every operator?

No, we don't. If you look at the proposal a second time, please note the part:

"First, we provide a way to turn off ADL for non-operator names"

So, "using = delete;" isn't intended to affect operator names. The above code would still work as before.
 

Third is that there's useful idea that non-member functions should be preferred over member functions in class design.

Having ADL for free functions that form a part of public interface of a class is actually a good thing.

 

My idea is that it's not the user of a function has to decide whether it should be found by ADL, it's the author of a class.

For example, we could declare such functions with operator keyword. It is expected for operators to be found by ADL anyway.

 

template<typename T>

void operator swap(T& first, T& second);

 

Going further, we may allow to call operator functions as member functions. Then, there would be no need of notion of pure ADL, used for range-based for loop.

 

I know that there a lot of subtle details that should be figured out. And that's limiting ADL only to set of specially declared functions is a big change and should be done in stages.

But if we are going to fix ADL, then my understanding is that it should be fixed in this direction.

I think that both approaches make sense.

- Daniel

[Felipe Magno de Almeida]

Hello, this is my first message on this group. If I'm doing something
wrong, please warn me.

On Sat, Nov 10, 2012 at 11:34 AM, <grigor...@gmail.com> wrote:
>

[snip]

> My idea is that it's not the user of a function has to decide whether it
> should be found by ADL, it's the author of a class.
> For example, we could declare such functions with operator keyword. It is
> expected for operators to be found by ADL anyway.
>
> template<typename T>
> void operator swap(T& first, T& second);
>
> Going further, we may allow to call operator functions as member functions.
> Then, there would be no need of notion of pure ADL, used for range-based for
> loop.
>
> I know that there a lot of subtle details that should be figured out. And
> that's limiting ADL only to set of specially declared functions is a big
> change and should be done in stages.
> But if we are going to fix ADL, then my understanding is that it should be
> fixed in this direction.

I really like the idea of named operators. It seems it would break a lot of
code though.

> Regards,
> Gregory

Regards,
--
Felipe Magno de Almeida

[grigor...@gmail.com]

Субота, 10 листопада 2012 р. 15:40:33 UTC+2 користувач Daniel Krügler написав:

"First, we provide a way to turn off ADL for non-operator names"

So, "using = delete;" isn't intended to affect operator names. The above code would still work as before.
 

 

 

My mistake, I should have read paper more carefully.  

[grigor...@gmail.com]

 

Субота, 10 листопада 2012 р. 17:22:35 UTC+2 користувач Felipe Almeida написав:

I really like the idea of named operators. It seems it would break a lot of
code though.

Regards,

--
Felipe Magno de Almeida

 

Named operators by themselves would not break code. Named operators + disabling ADL for non-operator names may break library code, however I do not propose to disable it in one step.

Now I think that N3490 and named operators complement each other. And at some point (e.g. for C++20) we may make

 

using = delete;

 

the default behavior and introduce means to switch to old behavior.

 

Named operators + calling them as member functions - the feature has to be designed in a way that breaks as little code as possible - e.g. operator function should be only considered if member function was not found.

[Tony V E]

I like "operator function".

Fixing ADL is a big job, not sure how we could fix old code, but I like the idea of marking functions as "want ADL".

And the use of operator keyword.

<please excuse the top posting, I blame mobile devices>

Tony

---

From: "grigor...@gmail.com" <grigor...@gmail.com>
To: "std-dis...@isocpp.org" <std-dis...@isocpp.org>
Sent: 10 November, 2012 8:34 AM
Subject: [std-discussion] Thinking about ADL

The most severe problem with argument-dependent lookup is that most of C++ programmers even experienced ones have no idea what it is.

On the other hand it allows operators to work as expected by most programmers and also allows to connect free functions to class.

So, I guess the consensus is that ADL has to be fixed by no-one knows how to fix it right.

 

A recent proposal by Dave Abrahams N3490 is written from a perspective of a library author. He argues that is sufficient to provide facility to explicitly disable ADL by

 

using = delete;

 

And then explicitly  enable ADL for some of functions expected to be found via ADL by

 

using swap;

 

The solution might be acceptable for library code but I do not think that it would work for user code.

First of all, in order to disable ADL users have to be aware of ADL. Second adding  'using = delete;' will break even hello world program

 

#include <iostream>
using = delete;

int main()
{
    std::cout << "Hello, world!" << std::endl; // operator << is not found 
    return 0;
}

Do we expect users to write 'using' for every operator?

 

Third is that there's useful idea that non-member functions should be preferred over member functions in class design.

Having ADL for free functions that form a part of public interface of a class is actually a good thing.

 

My idea is that it's not the user of a function has to decide whether it should be found by ADL, it's the author of a class.

For example, we could declare such functions with operator keyword. It is expected for operators to be found by ADL anyway.

 

template<typename T>

void operator swap(T& first, T& second);

 

Going further, we may allow to call operator functions as member functions. Then, there would be no need of notion of pure ADL, used for range-based for loop.

 

I know that there a lot of subtle details that should be figured out. And that's limiting ADL only to set of specially declared functions is a big change and should be done in stages.

But if we are going to fix ADL, then my understanding is that it should be fixed in this direction.

 

Regards,

Gregory

 

 

 

 

 

 

 

 

 

 

--
 
 
 

[FrankHB1989]

A name is a use of identifier, operator-function-id, literal-operator-id, conversion-function-id, template-id, etc. Operators appeared out of unqualified-id are not took into account. So there is simply no need to worry about this 'hello world'.

[grigor...@gmail.com]

Четвер, 15 листопада 2012 р. 20:58:04 UTC+2 користувач FrankHB1989 написав:

A name is a use of identifier, operator-function-id, literal-operator-id, conversion-function-id, template-id, etc. Operators appeared out of unqualified-id are not took into account. So there is simply no need to worry about this 'hello world'.

Sorry, I did not quite get your comment.  

[FrankHB1989]

在 2012年11月16日星期五UTC+8上午6时36分04秒，grigor...@gmail.com写道：

Четвер, 15 листопада 2012 р. 20:58:04 UTC+2 користувач FrankHB1989 написав:

A name is a use of identifier, operator-function-id, literal-operator-id, conversion-function-id, template-id, etc. Operators appeared out of unqualified-id are not took into account. So there is simply no need to worry about this 'hello world'.

Sorry, I did not quite get your comment.  

Sorry, please forget it. I've misread N3490. 'using operator = delete;' is actually "a way to turn off ADL for operators", where "operators" also include overloaded operators, not only named function operators.

[Reverend Chip]

On 11/10/2012 5:34 AM, grigor...@gmail.com wrote:

The most severe problem with argument-dependent lookup is that most of C++ programmers even experienced ones have no idea what it is.

On the other hand it allows operators to work as expected by most programmers and also allows to connect free functions to class.

So, I guess the consensus is that ADL has to be fixed by no-one knows how to fix it right.

I disagree.  From your own description, the consensus is that it needs to be explained.  Once coders understand it, they will be content.

[gr...@ciklum.com]

We are not living in perfect world where every C++ programmer is exprert in C++. Every programmer knows a subset of language and there's no way we can force them to be interested in details of name lookup. However, usually programmers tend not to use constructs they do not fully understand. The problem with current definition of ADL that it applies to all unqualified calls that is to vast majority of calls. There's no way for ordinary programmer to stop using ADL.

If we limit ADL so that it would apply to most calls the problem disappears.

[gr...@ciklum.com]

edit:

If we limit ADL so that it would not apply to most calls the problem disappears.

[Ville Voutilainen]

On 16 November 2012 16:46, <gr...@ciklum.com> wrote:
> edit:
> If we limit ADL so that it would not apply to most calls the problem
> disappears.
>
> On Friday, November 16, 2012 4:41:40 PM UTC+2, gr...@ciklum.com wrote:
>>
>> We are not living in perfect world where every C++ programmer is exprert
>> in C++. Every programmer knows a subset of language and there's no way we
>> can force them to be interested in details of name lookup. However, usually
>> programmers tend not to use constructs they do not fully understand. The
>> problem with current definition of ADL that it applies to all unqualified
>> calls that is to vast majority of calls. There's no way for ordinary
>> programmer to stop using ADL.
>> If we limit ADL so that it would apply to most calls the problem
>> disappears.

I'm not quite convinced about that "vast majority of calls". The vast
majority of the C++
programming I've been doing in the last 14 years was performed under a
coding style
that bans all unqualified calls except for operators.

[gr...@ciklum.com]

We have different exprerience. In companies I worked on namespaces were used sporadically and most calls were unqualified.

Recently I have found using namespace std; in header file in some old component.

[gr...@ciklum.com]

coding style
that bans all unqualified calls except for operators.

 

Does that apply to calls to functions in the same namespace as calling function?

[Ville Voutilainen]

Yes. On the whole it applies to rather few functions because the style often
had member functions rather than non-members, so it's at best anecdotal,
and I'm definitely not against adding facilities to control ADL, I very much
like what Dave proposed.

[grigor...@gmail.com]

His proposal is fine if the position on ADL is that it was a mistake to allow ADL for non-operator names from the very beginning.

And that we should ban it and provide an escape hatch for libraries that rely on ADL. I cannot treat 'using swap;' in any other way.

As general facility that should be used by ordinary programmer it is horrible.

 

What I am talking about is fixing ADL in such way that also provides a feature analogous to extension methods of C#.

Would such feature be a valuable tool when dealing with code where most of functions are methods?

 

 
Пʼятниця, 16 листопада 2012 р. 18:20:11 UTC+2 користувач Ville Voutilainen написав:

[J. Daniel Garcia]

What is a mehtod?

Do we have such a term in C++?

I know what a member function is, although I do not have any precise definition of mehtod in the context of C++.

--
 
 
 

[grigor...@gmail.com]

Method is an OOP term.

http://en.wikipedia.org/wiki/Method_(computer_programming)

 

C++ as multi-paradigm language supports object-oriented style, so terms of OOP have mapping to terms used in C++.

You may dislike it, but I hope that everybody understands what it means.

Субота, 17 листопада 2012 р. 14:29:27 UTC+2 користувач josedaniel.garcia написав:

[Jean-Marc Bourguet]

Le samedi 17 novembre 2012 14:04:01 UTC+1, grigor...@gmail.com a écrit :

Method is an OOP term.

http://en.wikipedia.org/wiki/Method_(computer_programming)

 

C++ as multi-paradigm language supports object-oriented style, so terms of OOP have mapping to terms used in C++.

You may dislike it, but I hope that everybody understands what it means.

I don't. Excepted when using the context to disambiguate, I never know if "method" means
- member function (static or not, virtual or not)
- non static member function (virtual or not)
- virtual member function
I've met people holding that their choice is the correct one, but they don't agree between them and there is no authoritative definition for C++.

Yours,

--
Jean-Marc Bourguet

[J. Daniel Garcia]

+1

--
Jean-Marc Bourguet

--
 
 
 

--
Prof. J. Daniel Garcia
Associate Professor - Profesor Titular de Universidad
Computer Architecture Group
University Carlos III of Madrid
Avda. Universidad Carlos III, 22
28270 Colmenarejo, Madrid. Spain
Tel: +34 918561316
Fax: +34 91 856 1270
e-mail: josedani...@uc3m.es
Web: http://www.arcos.inf.uc3m.es/~jdaniel
 
Linked-In: http://es.linkedin.com/in/jdanielgarcia
Twitter: http://www.twitter.com/jdgarciauc3m

[grigor...@gmail.com]

I used it as a synonym for member function (possibly static, possibly virtual).

Субота, 17 листопада 2012 р. 15:21:50 UTC+2 користувач Jean-Marc Bourguet написав: