Andrey Semashev

BTW, `std::rotate` is terrible. I can never remember what it does.

> it's _really really good_ to put them lexically in that order. Sorry, I don't see why, aside from personal preference. IMO, the least confusing interface is "good", and the...

I don't think adding constructors from iterators is a good idea, unless we can require [contiguous iterators](https://en.cppreference.com/w/cpp/iterator/contiguous_iterator). Which means these constructors would only be available in C++20 and onwards.

Dereferencing end iterator would be UB. Also, I don't like a runtime assert. The code should simply not compile, otherwise it's too bug-prone IMHO. At most, we could hardcode `std::vector::iterator`...

Requiring the users to type it makes them aware what they are doing. While accepting iterators and doing it internally could hide a bug. For example, when the span is...

> Iterators from deque that pass the assert will actually form a valid span. This would be runtime-dependent. Meaning the code will pass or fail from one run to another,...

> If we really want these constructors in pre-C++20, let's restrict them to being pointers only. Actually, let's add a new `is_contiguous_iterator` trait that will be usable outside `boost::span`. For...

> Yes, but we can't reliably reject it at compile time while allowing the correct cases without C++20. It's obviously a tradeoff that errs towards accepting the correct cases in...

I'd rather we didn't specialize `is_contiguous_iterator` for `std::string` and `std::vector` iterators as it would necessitate including the respective standard library headers and that might be too expensive. Note also, there...

Specializing for iterators is just not scalable. What about non-std iterators? IMO, specializing only for non-`void` pointers is enough. People who want to construct spans from iterators in pre-C++20 can...