Koenig lookup, names in std:: - Summary

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2001-01-24 10:12:00

I think the various issues which have come up in the course of my recent
changes to rational.hpp could do with a summary. I believe that the issues
are:

1. In the absence of Koenig lookup, it is effectively impossible to find the
appropriate implementation of a function which acts on a value of a template
parameter type. This isn't too surprising, as it is the issue Koenig lookup
was designed to address. It hits the rational class in two places - in the
implementation of gcd() where picking a suitable swap() function could be a
big win in performance, and in the implementation of abs() where it is
clearly the right thing to do to defer to the underlying integer type's
definition of abs().

2. As an alternative approach, code could only look in std:: for functions
like swap() and abs(). For this to work, user-defined types would be
required to inject suitable overloads/specialisations of the functions into
the std:: namespace. This seems natural and sensible (to me) - why should
implementations of a function be scattered across multiple namespaces?
Unfortunately, the wording of the standard makes this illegal. It's not 100%
clear (to me, at least) that this was a deliberate prohibition, as opposed
to an unfortunate consequence of the wording. Nevertheless, there seems to
be no practical likelihood of such injection causing actual breakage. There
seems to be some indication that the committee may remove the restriction on
injecting overloads into std:: at some point.

3. Using Koenig lookup requires that names are unqualified, which in turn
means that a using statement is required. I, personally, find the fact that
a using statement plus an unqualified name behaves differently from a
qualified name a little surprising and unintuitive. I'd tend to feel that it
warranted an explanatory comment, at least.

4. Implementations can provide built-in integer types other than the
standard ones. While it is clearly a quality of implementation issue, it
isn't possible to guarantee that there will be an implementation of
std::abs() for non-standard integer types.

This summary isn't entirely unbiased - I'm sure you can detect my
preferences in the wording. Nevertheless, I hope that it manages to
summarise the issues reasonably fairly.

As a consequence of these issues, there are a number of questions to be
answered. What I'd like to do is to ask the questions, then collect any
comments over a period, and then come to a decision for the rational
library. I propose to wait until mid next week (the end of the month, for a
specific date) and then collate any replies.

Questions
---------

1. Should Boost libraries only look in std:: for functions specified in the
standard? This effectively requires users of the libraries to overload names
in std::, and prejudges the committee's decision on issue (2) above.

2. As an alternative, should Boost libraries use Koenig lookup on compilers
where it is supported, and use std:: for compilers where Koenig lookup is
not supported? This results in a difference in user interface between
compilers. For this to be reasonable, I'd say we have to advertise the
overloading of names in std:: as a workaround for lack of Koenig lookup,
which then makes it harder to switch to overloading std:: as a recommended
approach should the committee decide this is OK.

3. A third alternative is to mandate Koenig lookup, and say that
functionality which cannot be provided without it is not available on
compilers which don't support it. (I don't see this as adding anything over
(2), however).

4. Specific to the rational library, would anyone have any strong objections
if I were to implement abs() without using an existing abs() function on the
underlying integer type? Apart from the Koenig lookup issues, I don't really
want to break the use of rational<long long>, rational<__int64> and the
like.

Thanks for any comments people may have, and for everyone's patience in
putting up with my E-mail brain dumps over the past few days...

Paul.