That was one of the things that pained me the most. We should really have something like __builtin_ranges_overlap without all the UB

I love it

First, thanks a lot for working on this, I am really excited that this is gaining traction.

Just to be sure, are there ABI concerns for span?

LGTM

I like the test coverage but I believe that we should get @CaseyCarter on board to port the ranges test machinery over. It is quite extensive and rebuilding it for the fun of it seems a waste of time

I can only speak from experience working on the MSVC ranges machinery. The join_view tests take about 5 min to compile.

I really like @ldionne suggestion. I am a bit unhappy about it being a macro, but meh.

Not a maintainer, but this looks good to me

I find the tests really hard to read and follow. I think giving the lambdas an explicit name would be really beneficial.

Thanks for working on this. It is a considerable library

@cjdb I am totally fine with dropping this revision. Thanks a lot for working on this!

Looks good to me

In D96842#2568789, @stephan.yichao.zhao wrote:

re "We can't change the API". Is this because C++ standard claims that std::vector<bool> must be specialized?

Can we keep all interfaces unchanged, and add some DFSan logic inside a method when the sanitizer is used?
For example, the problem we have is operator= does not propagate DFSan's meta data correctly, and the 'reserve' method does not initialize DFSan's meta data.
When DATAFLOW_SANITIZER is on, the code may add logic to initialize or propagate DFSan's information. This does not change interfaces.
Is this a better approach?

As far as I can tell the last clause from common_reference is specifically made for something like reference_wrapper types

Do we need tests for indirections like std::reference_wrapper?

Thanks for working on this. It is missing uglification but besides that I only have one small nit

In D74351#2547689, @cjdb wrote:

@miscco What is the status of this commit? I will review it on Wednesday if it's still in good shape.

This looks great, I have some minor concerns regarding the next version and whether we should already prepare for that

I love hat you start breaking up the headers.

As someone who has extensivly worked with conscepts I cannot stress how much this would improve my live

Awesome, thanks a lot!

In D92229#2420261, @mclow.lists wrote:

Has clang-format been improved enough that it will not "wreck" std::less<void>? Last time I tried it on that code, it pessimized it pretty thoroughly.
Code pasted here for reference:

#if _LIBCPP_STD_VER > 11
template <>
struct _LIBCPP_TEMPLATE_VIS less<void>
{
    template <class _T1, class _T2>
    _LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
    auto operator()(_T1&& __t, _T2&& __u) const
    _NOEXCEPT_(noexcept(_VSTD::forward<_T1>(__t) < _VSTD::forward<_T2>(__u)))
    -> decltype        (_VSTD::forward<_T1>(__t) < _VSTD::forward<_T2>(__u))
        { return        _VSTD::forward<_T1>(__t) < _VSTD::forward<_T2>(__u); }
    typedef void is_transparent;
};
#endif

I would like to note that with MSVC STL we simply work around those rare cases via //clang-format off. One main use case are requires clauses that are not yet supported. That said, the vast majority of the code works fine.

That would be interesting, but I believe that moving /splitting of lines should be common enough that it is already sorted out

I really like that we get clang-format to work. Live is simply to short to worry about formatting.

I am super in favor of using feature macros everywhere. That said I guess we need to thumbs up from the maintainers

One last ask for @ldionne, currently MSVC`s internal test runner seems to require int main() even in compile only tests, as it not yet understands compileonly tests. For the sake ofcompatibility could we for now include int main() {} to enable cross vendor compatibility.

I am wondering whether we should split the ranges header up into a smaller part that we use to include in other headers adn the rest.

If there is another earnest push for concepts / ranges we should get together with @cjdb, @ldionne to see whether we find a way to not step on our toes and duplicate work.

Some quick review of the the acutal changes to the headers

Note that I am not a maintainer and you should hold on until one accepts it too

I wanted to cry at the use of a comma operator, but all the other member functions do the same...

So the actual problem in the bug report is that the first argument cannot be used to deduce the type.

Thanks a lot for improving the test coverage!

@Quuxplusone I am totally fine with you adding the basic test.

I mean I do not really want to bother you, but the "correct" thing to do would be to actually not use int but one of the defined arche types (in this case one of those that count how many times they have been moved from.)

Could we remove from the middle to ensure that we do not tamper with the initial elements

@cjdb This was just a ping to see whether you are still interested.

Some small nits

Ping @cjdb I knowit has been a while but are you still planning on working on this?

• Fix formatting of meow.version.pass.cpp

Once again into the breach

Please use all the changes

Remove the unused member function from CountAssign

Thanks a lot for taking the time.

Missed some changes

Updated tests

Could someone have a look at this?

I would second @ldionne that we should add some static_assert(noexcept(...) tests

This looks obviously correct.

Took the opportunity to look through this again. Mostly nits about the tests

Ping, a second *pair* of eyes wouldn't hurt.

Thanks, that was what i expected but wanted to be safe

Do we need to reenable the test somewhere?

I am still having trouble to unterstand what benefit this has.

Thanks for working on this. I have some small nits.

I have to say that this is rather worse than what we had before.

I think this is the "least worse" solution to the mess that is array<T, 0>.