hardened std::span is the same as gsl::span

[tiagomacarios]

With various standard library implementing a hardened mode (see microsoft/STL#5090 for an example) would it be interesting for us to warn users to use that instead?

In larger codebases there is always some confusion on what to use. If we could create clarity that would be great. I am just brainstorming, but I wonder if having something like the below would be possible/helpful.

#ifdef _MSVC_STL_HARDENING_SPAN
#error use std::span instead
#endif

[DanielJump]

Mixed codebases could still need to use gsl::span, but I like the idea here.

[carsonRadtke]

hardened std::span is the same as gsl::span

Looks like microsoft/STL#5274 only hardens member functions. gsl::span also hardens iterators, so STL hardening isn't a replacement for gsl::span.

libc++ has hardened iterators too, so it may make sense to issue a diagnostic (I wonder if #warning is better than #error?) when we have _LIBCPP_HARDENING_MODE != _LIBCPP_HARDENING_MODE_NONE. This is the only implementation that, when hardened, is the same as gsl::span.

From what I can tell, libstdc++ does not offer a production-caliber hardening mode. There is _GLIBCXX_DEBUG which enables all standard library assertions, but I don't think anybody would use this in production.

I will bring this issue up during the monthly maintainer's sync. Perhaps Gabriel Dos Reis (@gdr-at-ms) has some additional thoughts.

[beinhaerter]

As Daniel Jump (@DanielJump) noted mixed codebases should be taken into account. I already had trouble with gsl::byte. I had a library that was built with C++17 and a program built with C++14 that uses this library. I got a linker error because one project replaced gsl::span with std::span and the other project used gsl::span. The symbols did not match. So it was necessary to #define GSL_USE_STD_BYTE 0.

If a warning is implemented here, it should be possible to switch that off in case two projects must be linked together where one is using hardened STL and the other is not using hardened STL. If of course the hardening changes object layout and thus binary compatibility, so it is not possible to link two projects together that use different hardening modes, then we do not need to care.

[carsonRadtke]

Maintainer's call: (See #1199) for now the action item is a documentation change. If there comes a time where we feel gsl::span is obsolete, we can consider ways to guide the user to std::span.