3 ms·
This is the best-engineered solution so far from a pragmatic point of view I have seen for C++ because it provides improvements with 100% compatibility. Sorry
by germandiago 4y ago
This is the best-engineered solution so far from a pragmatic point of view I have seen for C++ because it provides improvements with 100% compatibility.
Sorry for kind of x-posting (I posted in r/cpp the questions below), since I did not get any replies, but, Herb Sutter or anyone close enough, if you are around and have some time for questions... would love to hear more from this project.
I just saw the whole talk. Most ptomising C++ replacement so far for me: it is immediately useable and compatible and it does NOT duplicate standard lib and it is 100% compatible.
That said, here is my feedback/questions:
About pass by copy. Dave Abrahams in his value semantics talk says copy is too eager in C++. Swift for example uses something sinilar to COW, avoiding eager copies when passing parameters. This also makes all copies de-facto noexcept. Is this the idea with Cpp2?
About bounds checking: is it possible to call a non-bounds check function and detect it?
About bounds checking: why always checked access? There are contexts, for example in a range for loop, where checks csn be ellided safely. Also, if you do checking in a span subspan, that slice traversal should not need checks.
About bounds checking also: why the 3 subscript is a run-time error? I think it could be made a compile-time error for constants and constant folding.
About overloading: one thing not mentioned in the talk. how are overload sets handled when you introduce the same name in the same context if parameter passing now is a bit different?
About classes (no design yet, I know): there will be memeber functions vs free? How would overload resolution work? In case there are both memeber and non-member funcs, associated namespaces and so on. Also, it is interesting to look at Swift protocols and Val lang views here. Polymorphism comes from use, not from type itself.
about exceptions: is it compatible to have lightweight exceptions and exceptions? my concerns here are two: should I annotate with try the calls and the result type of the function is affected (returning some ki d of outcome, reault, etc.). This is really viral compared to throwing from deep stacks and less usable as a default IMHO.
Sorry for the typos. Typing from a phone.