Coexistence of GSL implementations

[mbeutel]

The Core Guidelines make clear that Microsoft's GSL is but one implementation of the GSL:

FAQ.51: Is github.com/Microsoft/GSL the GSL?

No. That is just a first implementation contributed by Microsoft. Other implementations by other vendors are encouraged, as are forks of and contributions to that implementation. As of this writing one week into the public project, at least one GPLv3 open-source implementation already exists. We plan to produce a WG21-style interface specification to ensure that different implementations agree.

Existing implementations of the GSL do diverge in some details which are underspecified or seem questionable, so a precise interface specification would help. However, this doesn't address the question how different GSL implementations can coexist. This becomes a problem when using the GSL in library code; my function may accept a parameter of type gsl::span<>, but what if I use a different GSL than my caller?

I'd appreciate if the Core Guidelines editors could take up a stance on this. E.g.:

• Different GSL implementations cannot be expected to coexist. This would raise the follow-up question if the GSL should be used at all in libraries.
• The GSL is header-only, so we're fine if every translation unit uses only one of the implementations. This could still lead to link-time issues because there can be two distinct types called gsl::span<> in the same target.
• Every GSL implementation should use a dedicated namespace (e.g. ms_gsl, gsl_lite) and corresponding macro prefixes (ms_gsl_Expects(), gsl_lite_Expects()); it could still offer a convenience header which says namespace gsl = ms_gsl and which would be incompatible with the convenience header of competing implementations, but at least we get no link-time ambiguity.

[mbeutel]

Somewhat related issue: right now CppCoreCheck seem to hard-code some GSL type names such as gsl::span<>, gsl::not_null<>, gsl::owner<> (cf. gsl-lite/gsl-lite#240). If GSL implementations were encouraged to use their own namespace (e.g. namespace gsl_lite), the static analysis checks would no longer work. Instead of hard-coding them, perhaps the Core Guidelines should specify an attribute annotation such as [[gsl::span_type]], [[gsl::not_null_type]], [[gsl::owner_alias]] with which the corresponding types could be tagged?