Fix warning 4996 on Microsoft compiler

[suncho]

This addresses issue #621 in a more general way than pull request #622. By adding _Unchecked_type to span_iterator, the Microsoft standard library will assume that span_iterator is checked, which it is.

Pull request #622 wraps the span_iterator in a checked_array_iterator, which is redundant because span_iterator is already checked. Furthermore, #622 is only a very specific fix for gsl::copy in particular. The change in this pull request will allow you to use span_iterator for any of the STL algorithms without warning.

[neilmacintosh]

Thanks @suncho! I really like that this fix is small, simple and targeted.

[CaseyCarter]

I recommend not depending on undocumented implementation details of the MSFT STL: they are subject to frequent changes without notice.

[neilmacintosh]

@CaseyCarter: is there a documented/supported way that is broadly equivalent?

[suncho]

@CaseyCarter I looked for a documented way to tag an iterator as checked for Microsoft STL, but I couldn't find one. If there is a documented alternative, we should by all means use that instead. If this implementation detail of the Microsoft STL changes, the only thing that's likely to happen here is that the warning will come back. It shouldn't break anything in the span_iterator.

[CaseyCarter]

@CaseyCarter: is there a documented/supported way that is broadly equivalent?

Not really. Obviously stdext::checked_array_iterator is the tool we provide to get past the annoying deprecation warnings, but lack of portability makes it a very heavy tool. I usually recommend defining _SCL_SECURE_NO_WARNINGS to disable the bogus warnings.

In fairness to the solution, we conventionally define macros using all uppercase so even if we do change the meaning of _Unchecked_type it's unlikely to ever launch the missiles.

Another internal implementation detail that you should TOTALLY NOT depend on: range-based-for looks for _Unchecked_begin and _Unchecked_end and prefers them to begin and end when available. Adding members with those names to span would enable code generated for range-based-for loops -
which always traverse exactly the proper range - to avoid span's range-checking machinery.