[mratzloff]

I realize that almost every language could be described as a subset of C++, but I read articles like this and think...

Deterministic language that has type inference, C interop, and uses ownership to govern object lifetimes? We have that. It's C++11. auto with std::unique_ptr and std::move().

Only slightly serious. ;-)

[sitkack]

So Carp could compile to that subset of C++. But C++11 isn't _just_ that. It is all of C++11.

C++ would even more successful if it was easy to make a proper subset of it.

[geokon]

That's what the GSL was supposed to be

https://github.com/Microsoft/GSL

It seemed really cool. All compile time checks. I have no idea why it didn't take off

[duneroadrunner]

The problem is that, while in many ways an improvement over traditional coding practice, the subset of C++ associated with the Core Guidelines (GSL stands for "(Core) Guidelines Support Library") has turned out to be a dead-end when it comes to memory safety. In fact it formalizes the depenedency on intrinsically unsafe elements like native pointers, std::shared_ptr, etc. I mean, with "regular" C++ you're not actually obligated to use those intrinsically unsafe elements. With the Core Guidelines you are.

SaferCPlusPlus[1] is an alternative subset of C++ that doesn't have that same problem. It achieves memory safety by simply excluding the intrinsically unsafe elements and providing memory-safe alternatives.

> All compile time checks.

Not quite in reality. One small issue with the GSL, for example, is that its not_null pointer class does a run-time check on every pointer dereference[2]. SaferCPlusPlus can enforce "not null"ness at compile-time.

A bigger example, for instance, is the situation where you want to allow multiple threads to simultaneously modify different parts of an array. With SaferCPlusPlus, this is straightforward and safe [3]. With the GSL/Core Guidelines, less so.

I don't know how much these technical considerations factor into (or will factor into) popularity of adoption. I don't know how big the intersection is of the sets of developers who take code safety seriously and those who remain interested in C++.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/Microsoft/GSL/blob/1c95f9436eae69c9b93159...

[3] https://github.com/duneroadrunner/SaferCPlusPlus/blob/278b40...

[pjmlp]

Sure it did.

Some of the new C++17 library updates come from there, and both clang and VC++ implement those static checks.

[geokon]

I've only have a pretty basic understanding of how it works, but I thought the checks didn't rely on the compiler. They're special templates that fail when their conditions aren't met

And when I say it didn't take off - I mean that I haven't come across a single large project that has take up using the GSL. Hope I'm wrong - maybe I just haven't looked in the right place?

[pjmlp]

No, GSL is a kind of stop-gap solution, until standard catches on.

For example std::string_view and ongoing design on std::array_view are based on gsl::span. The gsl::byte is also no longer needed on C++17 thanks to std::byte as yet another example.

The GSL asserts are there until code contracts[0] get into the standard.

The magical types like gsl::owner allow clang-tidy and VC++ checkers to apply a Rust-like memory tracking usage.

Kate Gregory did a presentation at CppCon 2017.

"10 Core Guidelines You Need to Start Using Now"

https://www.youtube.com/watch?v=XkDEzfpdcSg

As for not taking off, being initially a Microsoft proposal, it is surely used by Office and Windows teams, specially given they already use SDL (Security Definition Language) macros as well.

[0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p054...