ODR violation in ranges

[Tam S. B.]

IIUC using lambda in inline variable initializer is not ODR violation. This is covered in CWG 2300 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1510r0.html#2300 ).

________________________________________
From: Libstdc++ <libstdc++-bounces@gcc.gnu.org> on behalf of Jonathan Wakely via Libstdc++ <libstdc++@gcc.gnu.org>
Sent: Wednesday, March 11, 2020 10:26
To: Nathan Sidwell
Cc: libstdc++@gcc.gnu.org; GCC Patches
Subject: Re: ODR violation in ranges

On 11/03/20 06:08 -0400, Nathan Sidwell wrote:
>Jonathan,
>the ranges header contains code like:
>    inline constexpr __adaptor::_RangeAdaptorClosure all
>      = [] <viewable_range _Range> (_Range&& __r)
>      {
> if constexpr (view<decay_t<_Range>>)
>   return std::forward<_Range>(__r);
> else if constexpr (requires { ref_view{std::forward<_Range>(__r)}; })
>   return ref_view{std::forward<_Range>(__r)};
> else
>   return subrange{std::forward<_Range>(__r)};
>      };
>
>(line 1236)
>
>When you strip away all the templateyness, you have:
>
>
>inline constexpr auto all = [] () {};
>
>
>That's an ODR violation -- the initializers in different TUs are not
>the same!
>
>As you can guess, I can't turn this into a header unit (well, I can,
>but merging duplicates complains at you)

CC libstdc++@ and Patrick.

I did wonder if using lambdas for those global variables would be OK.

I think we'll need a new class template for each view adaptor, rather
than using the _RangeAdaptorClosure to hold a closure.

Patrick, can you look into that please?