Sounds like we're trusting a lot to the compiler. Will this lead to me making a small change which breaks an optimization in some distant code and ruins performance?
In 2028, we will still be writing code in C and Fortran. And there will be all these new languages X++ that would be promising to replace either or both ;) ;) ;)
Taylor Swift’s subject-oriented programming language – Swifties.
It would have:
• garbage collection (Shake It Off)
• error correction (Bad Blood)
• closures (Closure)
• optionals (Would’ve, Could’ve, Should’ve)
• automatic reference counting (Right Where You Left Me)
• REPL (I Knew You Were Trouble)
• variable mutability (Everything Has Changed and Evermore)
• guard condition (Eyes Open)
• strict typing (You Belong With Me)
After compiling run the binary by issuing the command: Run {filename}
I was almost murdered a few years ago when I told a classroom full of senior girls at a suburban high school that Taylor Swift was overrated (I just wanted to see what would happen if I poked the bear).
That is all I know about Taylor Swift. But it seems like you are onto something here. :D
I believe rust is sort of similar in that apart from the references, it's very heavy on the move semantics. And IIRC, sometimes it's doing extra memcpys. But I don't know if Rust is explicitly targeting const reference passing.
That said, if you're all in on it I imagine that the front-end could pretty aggressively target that, much like how rust uses no alias.
By default, non-references in Rust are passed by move, although you can derive `Clone` on types composed of all `Clone` types and then explicitly call the `.clone()` method to copy things. The only types that will be copied by default are the ones that implement `Copy` in addition to `Clone`, which in the standard library is on primitives like integers and characters but overall is used fairly sparingly.
References need to be specified as mutable if mutation is needed (i.e. `&mut T` instead of just `&T`). Using immutable references is also encouraged from the borrow checking rules; having a second reference (either mutable or immutable) alive at the same time as a mutable one is a compiler error, but using multiple immutable references at the same time is fine. (Pointers are the same way, but not really used much outside of bridging with unsafe Rust, since they can be null and therefore can't be dereferenced outside of `unsafe` blocks).
I think OP was referring to the fact that implementation of moves can sometime (more often than desired I would add) do memcpys. e.g. if you have a struct of ~100 bytes and you move it, it will probably emit a memcpy to write it in the receiving function's stack. AFAIK this happens because addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code. I don't think Val would have the exact same problem because it doesn't have the concept of addresses/pointers.
> AFAIK this happens because addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code. I don't think Val would have the exact same problem because it doesn't have the concept of addresses/pointers.
I honestly don't understand what you've said here at all. I'm not familiar with what "observable" means in this context, and googling "observable aliases programming languages" didn't help clarify it (two results were articles about C/C++ aliasing, one of which used the term "observable" once but didn't seem to define it at all, and the other which was the Wikipedia article on "Aliasing (computing)" that didn't contain the term at all).
Even if I knew what "observable" meant, I think you might be missing a negation (or maybe including one you didn't mean to) somewhere; if addresses are "kinda considered observable", it's not obvious why it would be an issue to omit copies and "be observable". Maybe understanding what's meant by "observable" would shed some light on what you mean here, but naively, I don't understand how code that expects things to "kind of" hold a property would break if that property were somehow more strongly held.
> addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code
This is certainly the case in c++: distinct objects have distinct addresses, so to remove a copy the compiler has to prove that the aliasing is not observable which is hard.
