Decide what you want. Performance of C++ or runtime overhead of Java/ObjC.
I want the performance of C++ , and removal of the problems orthogonal to that (header files, mutable default, ambiguity between method & function call syntax, closed classes). Productivity tweaks to reduce the number of cases where interfacing to Lua/C# is a win.
And I'm inspired by these reference cases to see something that should be possible: The ability to closely work with language X, with modernised language Y. replace X=Java/ObjC/C++. Y=Scala/Swift/(hopefully rust..)
You can't interface with a class that does not exist because it was optimized away by the compiler.
you can translate source to make equivalent descriptions for the inlining engines. Between Rust and C++ there is a very significant overlap where concepts have a 1:1 representation. This is where I want to be.
Do I want to isolate myself from established C++ sources ? hmm.
If it hast three parameters it does not work. This might seem trivial for add but it is not trivial to see for more complicated signatures.
With maths code the number of arguments is the easiest bit to get right. I think about what functions I want, then pick the data layout that suits those operations... everything centres on functions and data . Many representations re possible with subsets of operations making sense.. overloading/polymorphism is the rule rather than the exception and traits seem to become extraneous, often just a clone of the name.
Naming is hard, but the plus side of overloading is you leverage the names you already created- and we already have IDE's to search. Its headers that complicate it (this code will only compile if you included the right declarations first..)
Yes. But this is at the wrong place. This could happen after you compiled your library and delivered it to someone.
the best libraries are developed in an application then extracted, so you have the working application as an example of how to use it.
The traits are still there to improve the error messages.
you could still re-order and compress the error message using the information in the trait. (that, basically , seems to be what traits achieve: - I'm not dealing with vtables. I do appreciate the elegance that they're unified, sure, i do prefer rusts idea to multiply inheritance in the case where vtables are needed)
"can't call X because trait Y is not satisfied (because function Z isn't found"
"function Z not found for trait Y needed for call to X"
"trait Y not satisfied , because function Z not found, (needed for call to X,here)"
Whichever way it makes sense. The information is the same, 'some piece of code is yet to be written'.
This retrofit is going to be available in C++ - alone it's not a big enough reason for the world to throw away billions of LOC, (or for me to reduce my productivity)
So this is where Rust creates the ambiguity for me. If I go back to C++ and wait for C++ modules & concepts I'll get what I want... plus keep established tools and ability to work with established sources.
This would be a great shame, because Rust has a cleaner syntax and other tweaks that are really nice.. (like the expression oriented syntax, immutable default, nice macro system).
The language engine seems powerful enough to handle both styles. Its just like a compulsory restriction prevents it.
Being able to "accidentally" implement a trait without realizing it (especially a trait from some other crate you have no knowledge of) seems like a footgun waiting to happen to me.
If all the type signatures have to match, i think accidental implementation would be rare enough not to worry.
but we already have this hazard, and ways of dealing with it. IDE's can trace all the overloads . People have the software they need written in C++, and they want these sources maintained and extended. Do we have to throw away all this code to get (a) immutable default (b) no headers, (c) expression based syntax (d) ADTs (e) safety checks for new code (f) extention methods (g) better macros?... these are additions, not removals.
you've got these deep namespaces, and no overloading, and traits - it feels like it goes too far with naming sometimes