Some questions: move, ctors, operator overloading

[MBkkt]

I think something like move ctor/assign should be in language. Will it be like rust, with destructive move? Or like c++? I think both approaches have some pros and cons.

Also about constructors and operator overloading, if carbon will be without exceptions looks it looks like a bad idea to have them

So what your thoughts about that?

[geoffromer]

Yes, Carbon will support move semantics; see p0257. In particular, we are experimenting with a hybrid of destructive and non-destructive semantics that we are hoping will combine the advantages of both.

[MBkkt]

@geoffromer thanks, I checked that about other questions?

Also about move:

Disadvantages: Doesn't compose with pointers and C++ idioms which involve moving out of non-local objects through a pointer. Would require redesigning systems to model the lifetime in the type system.

I like destructive move more but Rust have other cons:

• not to be able pointer to self (libstdc++ sso string (same for vector, etc, we can implement only flag implementation))
• main issue from my point of view: runtime bool in some statements (need to call dtor or not), I don't think it's dramatic bad (in current state at least, but was really bad in early rust) Check this https://github.com/rust-lang/rfcs/pull/210 and maybe this https://rust-lang.github.io/rfcs/2094-nll.html It's about early drop, maybe with something like this it will be better.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.

[chandlerc]

Sorry this fell off folks radar...

about other questions?

We expect to need something analogous to operator overloading to really retain the same kind of expressive library API capabilities as C++ provides, but we're using a pretty fundamentally different approach to get there that we think will address many problems with it.

Similarly, we are using a different approach to constructors somewhat fundamentally.

Both of these are covered in the design overview.

Also about move:

Disadvantages: Doesn't compose with pointers and C++ idioms which involve moving out of non-local objects through a pointer. Would require redesigning systems to model the lifetime in the type system.

I like destructive move more but Rust have other cons:

• not to be able pointer to self (libstdc++ sso string (same for vector, etc, we can implement only flag implementation))
• main issue from my point of view: runtime bool in some statements (need to call dtor or not), I don't think it's dramatic bad (in current state at least, but was really bad in early rust) Check this Static drop semantics rust-lang/rfcs#210 and maybe this rust-lang.github.io/rfcs/2094-nll.html It's about early drop, maybe with something like this it will be better.

We're definitely looking at all of these options. We also have some challenging constraints due to interoperating with C++. As mentioned, we have a plan involving a hybrid approach that so far looks promising.

---

I'm going to convert this to a GitHub discussion as this isn't really an issue BTW. We also have an active language questions channel on our Discord.