Feature Request: Adopt SaferCPlusPlus to be more memory safe

[WSLUser]

Describe the bug
A clear and concise description of what the bug is. Please check that you've
read the guidelines for submitting STL bug reports in README.md. If you are
having problems with any component that is not the STL, instructions to get
to the right place are there.

C++ is not inheritantly a memory or data race safe language. Adopting this project will allow users of the STL library to ensure memory violations or other dangerous behaviors that could lead to exploitation are reduced.
isocpp/CppCoreGuidelines#1038 especially has some lively discussion about the problem though that particular issue is more specific to std:string_view.

Expected behavior
A clear and concise description of what you expected to happen. Alternatively,
include static_asserts or asserts in your test case above whose failure
clearly indicates the problem.

I expect to not worry as much about memory or data race safety as much due to the default of STL providing this safety net.

Additional context
As per the README, it's mostly drop-in replacements. See https://github.com/duneroadrunner/SaferCPlusPlus/blob/master/README.md for further information about why this should be adopted and example usage.

Side Note: I first filed this with the Windows Terminal project and the maintainers requested this be implemented in STL instead.

[sylveon]

This repo is purely for implementing the C++ standard library, not adding huge things even if considered beneficial or removing some parts of it (like SaferCPlusPlus's std::string_view replacement preventing construction via raw character pointers which the standard library allows - this will assuredly break existing code, including mine).

This is more suitable as a proposal to the C++ committee.

There are tools like ASAN and UBSAN to make programming safer without changing the standard library.

[WSLUser]

Yes and there's large information about the deficiencies in ASAN and other sanitizer tools in that README that point out all their problems and what makes it better to do this from code side. Also, it appears this repo already uses GSL. So if GSL can be used so can this project. The idea is make the language safer and better for everyone. While I'd prefer at the individual project level to ensure this, there are others within the same organization (MS) who would prefer that this project takes the mantle up instead.

[sylveon]

No, this repo doesn't uses GSL in any form, and MS itself can't make such huge changes to the standard library, it's up to the committee to do so.

[WSLUser]

Well as I originally added to my OP, this was requested to be done here. So let's have the MS staff make a judgement call on it. Maybe it could be an optional feature with a rename and some documentation stating this isn't per guidelines but advised for anyone who is worried about about memory leaks and other similar things and refer to the SaferCPlusPlus project for further information.

Also, seeing a few other issues, I was given impression that GSL was part of this project. If not, then I plan on creating an issue for that as well as using GSL wouldn't cause breakages unlike what this project might do.

[BillyONeal]

Using either GSL or this SaferCPlusPlus library here looks to be a layering volation: This is std::, and those assume std:: is available beforehand.

This repo is about implementing what's in the C++ standard, and I don't think maintaining a GSL-equivalent here is on topic.

[StephanTLavavej]

I was given impression that GSL was part of this project.

The STL and the GSL are completely separate projects, with different licenses. See: https://github.com/microsoft/GSL