Does carbon solve the fundamental issue in c++ which is referring / pointing to objects outside their lifetime

[Kubiyak]

Hello,
Does carbon provide any means of restricting references and pointers to objects?

The main issue with c++ is that references and pointers are allowed to all objects without discretion which invariably leads to references and pointers to objects after (or even sometimes before) their lifetimes.

Carbon only has relevance if it can provide some mechanism for an API designer to limit misuse of interactions with that API. Providing some means to bound and limit the taking of references and pointers to objects would be helpful. At least provide some means to prevent the passing of specfically designated types by reference. For example, it should not be possible to return specifically designated smart pointer types by reference. The RAII qualities of smart pointers are defeated by accessing the same via reference or pointer. I'm not suggesting that Carbon turn into Java but lets be cold and honest about why c++ fails.

If this feature exists, I will be a lot more interested in Carbon. Without this feature, Carbon is just a not so glorified IDE for c++. I'll stick w/ CLion if all Carbon can do for me is what an IDE can.

[geoffromer]

Safety, especially memory safety, is a top priority for Carbon. However, we are deferring that until the 0.2 milestone because we think we won't be able to design it effectively until we have more of the language foundations in place.

[Kubiyak]

That's fair but it would be useful to see some of the initial thinking and direction on it. What are the ideas being hashed out around it?

[geoffromer]

This recent keynote has a good overview of how we're thinking about memory safety in Carbon.

[Kubiyak]

Thanks for the link. I appreciate the response. I skipped through it and found this:
https://www.youtube.com/watch?v=1ZTJ9omXOQ0&t=1847s

I hope that there is some notion of not allowing reference expressions at all to certain types or reference counting the references also etc. Categorizing references may make sense but the distinction between temporary references and durable references doesn't help me write safer programs by themselves.

[geoffromer]

Carbon is certainly putting more emphasis on non-addressable values than C++ has, with things like let bindings and customizable value representations. I don't think we've discussed making whole types non-addressable, but I suppose it's possible, if it's well-motivated enough.

[Kubiyak]

Taking the address of an RAII type is a fail. Please consider providing a feature to tag certain types as non-addressable. I really appreciate your responsiveness and willingness to listen. Its a good sign. All the best.