Fix debugger visualizer for Ext=gsl::dynamic_extent

[pps83]

VS 2019 doesn't seem to match -1 for size_t template parameter, as a result dynamic span/basic_string_span/basic_zstring_span show extent as extent = 4294967295 (for 32-bit builds). This change updates details::extent_type to have static constexpr size_ parameter for non-dynamic span/basic_string_span/basic_zstring_span and simplifies/removes dynamic versions from GSL.natvis

fixes #856

[msftclas]

All CLA requirements met.

[JordanMaples]

The change looks good, I suggest wrapping the definition for size_ in a debug check since the template arg is used for all other operations.

[pps83]

The change looks good, I suggest wrapping the definition for size_ in a debug check since the template arg is used for all other operations.

.natvis works in release as well, are you sure that wrapping it in ifdef _DEBUG will not break it? I'd rather update extent_type to use size_ instead

[JordanMaples]

Maintainers' call: While you're correct that the natvis works for debugging code build with release, the natvis is ultimately a debugging tool. GCC and Clang users won't get any benefit from the additional size_ variable. We shouldn't force all consumers to pay for the ability to debug in release mode.

Please add the _DEBUG check and I'll merge it in. Thank!

[pps83]

Maintainers' call: While you're correct that the natvis works for debugging code build with release, the natvis is ultimately a debugging tool. GCC and Clang users won't get any benefit from the additional size_ variable. We shouldn't force all consumers to pay for the ability to debug in release mode.

Please add the _DEBUG check and I'll merge it in. Thank!

Can you please explain what kind of cost this change would introduce? It's a static variable, not much different than using template's Ext param directly. I'd even suggest doing it this way instead:
pps83@bacb9c5#diff-912da93c0c34962d231e98d0a2be2dc7

[CaseyCarter]

It's not only static, but implicitly inline so the variable definition won't be emitted into OBJs for translation units that don't use it - it's as close to free as you can get (https://godbolt.org/z/gUYExD). MSVC treats such inline constants specially and emits them into PDBs even when the program doesn't ODR-use them so they're accessible to the debugger for NATVIS purposes. (Most of the STL.natvis visualizers use enumerator constants for historical reasons, but more recent visualizers use static constexpr members like this.)

[pps83]

It's not only static, but implicitly inline so the variable definition won't be emitted into OBJs for translation units that don't use it - it's as close to free as you can get (https://godbolt.org/z/gUYExD).

I wanted to mention that inline consts would be even better, but GSL is C++14. I just realized that they are implicitly inline :)
@JordanMaples what do you think, should I update to PR to using static const (or enum)?

[JordanMaples]

@pps83 let's use the static const.

@CaseyCarter thanks for jumping in and clearing that up.