Consider renaming namespace ranges to range_v3

[cjdb]

The top-level namespace ranges will have the potential to clash with std::ranges, if people want to shorten std::ranges to ranges.

To prevent creativity and fragmented namespace aliases, I propose that range-v3 rename its top-level namespace to range_v3 or rangev3. Anyone who wants to keep range_v3 as ranges need only add an alias to get it back.

[beojan]

But why would anyone use both?

[cjdb]

C++20 has only a fraction of the support for ranges that range-v3 offers (fewer views, zero actions, zero numeric algorithms).

I'd like to use what's in the standard library where possible, and range-v3 everywhere else.

On Mon., 26 Aug. 2019, 10:05 Beojan Stanislaus, [email protected] wrote:

But why would anyone use both?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericniebler/range-v3/issues/1271?email_source=notifications&email_token=ACBZFHBXCSWL34TSAW6F77LQGOMENA5CNFSM4IOSDJC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5DY57Y#issuecomment-524783359, or mute the thread https://github.com/notifications/unsubscribe-auth/ACBZFHEXWXVAANQRI6ZJZHLQGOMENANCNFSM4IOSDJCQ .

[beojan]

Even where std::ranges includes views, the range-v3 is more fully featured, so why not just use the range-v3 version everywhere?

[cjdb]

1. One could be importing code from an external source.
2. Views that the compiler is aware of might have opportunities for optimisations that third-party libraries probably can't be offered.

On Mon, 26 Aug 2019 at 17:26, Beojan Stanislaus [email protected] wrote:

Even where std::ranges includes views, the range-v3 is more fully featured, so why not just use the range-v3 version everywhere?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericniebler/range-v3/issues/1271?email_source=notifications&email_token=ACBZFHAR23FRJWYVYULM2LLQGP73FA5CNFSM4IOSDJC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5E4KVA#issuecomment-524928340, or mute the thread https://github.com/notifications/unsubscribe-auth/ACBZFHB37URZ4BSOFPWUXTDQGP73FANCNFSM4IOSDJCQ .

[ericniebler]

The top-level ranges namespace will be a problem for folks who like to do using namespace std;, and that's plenty. Thanks for raising the issue. I don't love the idea of changing the ranges namespace though. I'll think about it.

[cjdb]

range-v3 could alternatively follow Abseil's approach and adopt what's in the standard library when it's available.

// example for range/v3/view/filter.hpp
#if defined(__cpp_lib_ranges) and __cpp_lib_ranges >= 201911
namespace ranges {
    using std::ranges::filter_view;
} // namespace ranges

namespace ranges::views {
    using std::views::filter;
} // namespace ranges::views
#else
    // as it is today...
#endif // __cpp_lib_ranges

It doesn't solve the using-directive issue, but I'm not as sympathetic to that as I am to making range-v3 interoperable with std.

[cjdb]

Another solution is to insert the current top-level ranges namespace into a new top-level namespace, such as range_v3. Then it'd be easier for folks to "build" their own ranges namespace.

E.g.

namespace ranges {
   using namespace std::ranges; // meta: goodness TBD
   using range_v3::ranges::concat_view; // TODO: remove when C++next adds this
   using range_v3::ranges::zip_view; // TODO: remove when C++next adds this
} // namespace ::ranges

namespace views {
   using namespace std::views; // meta: goodness TBD
   using range_v3::views::concat; // TODO: remove when C++next adds this
   using range_v3::views::zip_view; // TODO: remove when C++next adds this
} // namespace ::views

[Saring]

It is not possible to use this lib with gcc 10 and using namespace std; @ericniebler I understand you don't like the rename, but is there any other way how to fix it?

[ericniebler]

Don't do that? :^) I know that's less than helpful, but so is changing the namespace for a library that people have been using for 5+ years. There isn't a great answer here.

[slymz]

This is becoming curiously problematic as both C++20 is a reality and range-v3 still rocks.

Would a build/install-time namespace customization be useful to keep backwards compatibility while allowing custom top-level namespace for those who need this? Kind of like Boost does https://www.boost.org/doc/libs/1_75_0/tools/bcp/doc/html/index.html#bcp.syntax.options

[igorsugak]

@ericniebler this becomes a problem in fbcode. As C++20 is enabled code that uses (or just includes headers) ranges-v3 and does using namespace std; requires many ::ranges to compile, this includes range-v3 headers too.

[ericniebler]

At the prodding of @leehowes, here's the sketch of a solution that I would be happy to accept:

1. Define the top-level namespace as a macro (RANGES_V3_NAMESPACE) that can be configured at compile-time.
2. The macro defaults to rv3 or something equally short and pithy.
3. If the macro is not configured to be the string ranges then, define a (deprecated) namespace alias namespace ranges = RANGES_V3_NAMESPACE;. The deprecated attribute should have a message that tells people they can suppress the warning by configuring the library with -D RANGES_V3_NAMESPACE=ranges.
4. Add a config option to preprocess out the ranges namespace alias.

Instead of (4), another option would be to only include the ranges alias if RANGES_V3_NAMESPACE is not configured.

I think this would satisfy everybody? Although I don't have time to do this myself, I would gladly accept a PR.

[brevzin]

Just for info, {fmt} does:

#ifndef FMT_BEGIN_NAMESPACE
    #define FMT_BEGIN_NAMESPACE namespace fmt { inline namespace v9 {
    #define FMT_END_NAMESPACE } }
#endif

And then uses those two macros exclusively. If you want to change it, you have to define both.

[brevzin]

I guess this means I should also revisit #1472