Seconded that dipping a toe in to Rust has changed how I think about C++ and object ownership. Loose pointers and copy constructors now make me feel un-clean! Move ftw.

However I feel like most of the heavy lifting features came with C++11. Span, optional, variant and string_view are nice additions to the toolkit but more as enhancements rather than the paradigm shift of C++11 (move, unique_ptr, lambdas et-al).

> Seconded that dipping a toe in to Rust has changed how I think about C++ and object ownership. Loose pointers and copy constructors now make me feel un-clean! Move ftw.

It's funny, because while it's certainly become more influential lately, that subculture existed as a niche in the C++ world before Rust and before C++11. So much so that when I first heard about Rust I thought "these are C++ people."

The original (and long dead) Rust irc channel used to be full of C++ people chatting with OCaml people. Those were the days :)

That entirely matches my idea of how Rust came to be, some sort of pragmatic co-development across two different philosophical camps. In many ways, Rust is a spiritual successor to both languages, if only it was easier to integrate with C++.

lol i start most of my big objects by deleting the copy constructor and adding a clone member func :P

string_view, span and ranges are not conductive to safety, quite the opposite.

Yeah, if anything, C++ is getting less serious about safety by piling features over features. Just write Rust instead.

can you explain why you think that?

Things like "It is the programmer's responsibility to ensure that std::string_view does not outlive the pointed-to character array."

"string_view" is a borrow of a slice of a string. Since C++ doesn't have a borrow checker, it's possible to have a dangling string_view if the string_view outlives the underlying string. This is a memory safety error.

Rust has educated people to recognize this situation. Now it's standard terminology to refer to this as a borrow, which helps. Attempting to retrofit Rust concepts to C++ is helping, but often they're cosmetic, because they say the right thing, but aren't checked. However, saying the right thing makes it possible to do more and more static checking.

But surely it's a step towards more safety. Compare to passing char * around or ref/ptr to string.

Sure C++ doesnt have a borrow checker but these types encourage the idea of "reifying" lack of ownership rather than keeping it ad hoc

I have always used Pascal for memory safe strings. Reference counted, mutable xor aliased, bound checked: their safety is perfect.

Unfortunately there is no string view, so you need to copy the substrings or use pointers/indices. I tried to build a string view, but the freepascal compiler is not smart enough to keep a struct of 2 elements in registers.

You don't infer potential ownership from a C++ ref. Likewise for char* strings unless it is to interface with a C api, in which case you will keep it anyway.

Wow. I hadn't read up much on string_view but I guess I assumed it required a shared_ptr to the string. Odd decision not to.

Rust hasn’t "educated people" about "borrowing".

Lifetime management has always been there for any developer dealing with resources in any language. Over the years, languages and specialized extensions and tools have offered different solutions to help with that problem.

What Rust has brought is a system that checks explicit tracking embedded into a mainstream language.