As an update of what I've decided on doing: Following the advice of Paul
Bristow and Rob Stewart, I have decided to implement the range I/O stuff
as a new library with Boost.Range as a dependency. Once it's all up and
running and tested and such, I can ask Boost.Range's maintainers whether
they'd like to absorb it into Boost.Range or leave it as a separate
library (Boost.RangeIO?). Since the whole thing is already (more or
less) implemented as a standards proposal, all I had to do, really, was
just change the namespace from std to boost, and some other housekeeping
stuff. However, I decided to take the opportunity to examine a
possibility that a couple people have asked about: whether or not these
C++11 facilities can be made available to C++98 code. Looking into that
possibility is what's kept me occupied recently.
That's where I hit a little snag.
It turns out is probably *possible* to implement the facilities in
C++98... however, it is impossible to do so in a way that guarantees
safety. The problem is that C++98 has no way to prevent you from passing
a temporary to a function except by taking the argument by non-const
(lvalue) reference, which is too restrictive to help in this case.
The following code is perfectly safe in C++11:
std::vector<int> get_vec();
// as lvalue
std::vector<int> const v = get_vec();
write_all_t p = write_all(v, ", ");
// p contains a reference to v
// as rvalue
write_all_t p = write_all(get_vec(), ", ");
// p owns the vector
But in C++98 it takes a reference to the vector in both cases, which is
no good in the second case because the reference is dangling by the end
of the expression.
The only way to prevent binding to temporaries in C++98 is to take
arguments by non-const (lvalue) reference, but if write_all() does that
then the "as lvalue" code above won't work.
Boost.Move emulation doesn't help in this case, unfortunately. (See the
section "Emulation limitations". The relevant subsections are "Template
parameters for perfect forwarding" and "Binding of rvalue references to
lvalues".)
There is no way that the interface or design can be changed to avoid
this problem and still remain even marginally useful in practice - the
whole concept arose out of an observation of what rvalue references
would now allow us to do safely.
So my options come down to this:
1) Declare the library C++11-or-better-only. That can be enforced by
ensuring that BOOST_NO_CXX11_RVALUE_REFERENCES is not defined, and
issuing an error message otherwise.
2) Allow the library to be used in C++98 code, with a warning - either
in documentation or, less than ideally, as a diagnostic - about
temporaries. Note that there is no way to detect or diagnose if the
warning is ignored, deliberately or accidentally, so things that are
perfectly legal in C++11 mode can silently introduce undefined behaviour
in C++98 mode.
I'm leaning toward option 1, mainly for the reason that this is a
"syntactic sugar" library. It is not based on any non-portable
facilities - anyone can reimplement it on any conforming system - so it
doesn't provide "new" capability so much as it makes "old" capability
*much* easier. We got by without it for so long in C++98 that it's
obviously not the kind of thing people are desperate for - it's more a
really nice way to simplify common code, which to me implies it's the
kind of thing you will happily use if you can, but it won't cripple your
project if you can't. For a facility like that, I don't think it's a
worthwhile to introduce potentially undetectable bugs. Better to say "if
you can't use it safely, you can't use it - sorry, but just consider
this another motivation to move to C++11 when possible", which may irk
those developers who can't move to C++11, but c'est la vie.
I haven't found any official policy that *disallows*
C++11-or-better-only libraries (in fact, I stumbled on someone forking
Boost to make it *completely* C++11-or-better-only), and it seems to me
that relying on it is no different from a library relying on C++98
features that some compilers never got around to supporting. Obviously,
insisting on C++11 just for the sake of doing so would be silly, but in
this case the library *needs* a C++11 feature that cannot be emulated or
avoided (indeed, safe rvalue reference binding is just about the only
C++11 feature that falls into that category) - and the functionality it
provides is (IMHO) well worth it.
So unless anyone objects, I'm going to go ahead and make this "RangeIO"
library require C++11. (Specifically, I'm going to make it require
rvalue references - I'm not going to use any more C++11 functionality
than is absolutely necessary, so no auto or non-static member
initializers, etc.. For example, I will have it use
std::initializer_list, but only if BOOST_NO_CXX11_HDR_INITIALIZER_LIST
is not defined.)
