operator[] checks whether given index is valid.

[aforster]

I was interested in the reasoning for this bound check here and why that it is not guarded by #ifdef NDEBUG:

https://github.com/microsoft/GSL/blob/master/include/gsl/span#L613

This can be quite a big performance hit. Are the maintainers interested in a pull request that changes the Expects/Ensures macros when NDEBUG is defined?

[grahamreeds]

Usually it is the at() that does the bound checking. Does at() do bounds checking?

…

On Mon, 25 May 2020, 09:57 Andreas Forster, ***@***.***> wrote: I was interested in the reasoning for this bound check here and why that it is not guarded by #ifdef NDEBUG: https://github.com/microsoft/GSL/blob/master/include/gsl/span#L613 This can be quite a big performance hit. Are the maintainers interested in a pull request that changes the Expects/Ensures macros when NDEBUG is defined? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#889>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGL3HGQB6GI5CQJVZ7LUZLRTIXJJANCNFSM4NJLDXZA> .

[unixod]

Hi,
Alternatively to NDEBUG I suggest to consider also #877 where I proposed to return back the configuration options for Expects/Ensures, which existed before.

[JordanMaples]

The intended behavior of gsl::span is to guarantee bounds safety in all access operations, which is why we intentionally do not wrap these checks in NDEBUG.

[aforster]

Ok, I guess if this is by design I will close the issue.

[ericLemanissier]

well, C++ standards says that it's a precondition that the index is valid https://eel.is/c++draft/span.elem#1
If gsl::span has different assumptions that std::span, it would be wise to use another name for the class, to avoid misleading your users

[JordanMaples]

Maintainer's call: We actually are following the span design on purpose, however the only difference is the bounds checking. The intent is to be able to simply using a different namespace and it will still work.