Walter here - AMA!
A often recurring C idiom is passing a pointer to a struct as function argument where passing the plain struct by copy would do. A big reason is the good old 'passing by pointer is faster', which I thought to be no longer relevant with modern optimizing compilers. Of course I found out the hard way that even on modern compilers object copies are not elided on call. I had performance sensitive parts of my (non-x86) code that were dominated by the compiler's builtin memcpy, due to my struct-happy coding style (e.g. rolling my own range struct and passing it by value everywhere).
I understand mostly why eliding argument copy is so much harder than eliding a return object copy, there are so many ways to observe its effect, and you have to obey the calling convention. Another aspect is the lack of programmer-communicated immutability in C, which you have addressed with D. Does the D compiler help in this situation? Can it guarantee that (immutable) argument copies will be elided in certain circumstances? (e.g. in file-scope static functions)
No, but it's an interesting idea I never thought of. By the way, passing by 'ref' works handily and avoids icky pointer passing, while being efficient. I recommend as a "best practices" coding style using 'ref' parameters instead of pointers where possible.
Not even with old compilers, necessarily, this is more about the CPU architecture. If you've got an architecture with no cache (eg 386 and below for Intel) you'll not care about cache miss vs cache hit, but once you have cache you'll often find that the pointer dereference will hit main memory, and thus be slower than just passing by value. Not always, of course, but sometimes, so since 1989 (for Intel) you've needed to profile that to be sure.
It was then up to the callee to make a copy if necessary, say if it modified the struct contents.
Hence it would have been possible to elide the copies, on a per function basis, depending upon how the function used the structure.
[1] ftp://ftp.linux-mips.org//pub/linux/mips/doc/NUBI/MD00438-2C-NUBIDESC-SPC-00.20.pdf
I was also thinking in the direction of the compiler transforming the call-by-value struct object argument into a call-by-ref one at specific call sites. e.g. when the object is clearly on the caller's stack, is not mutated by the function and the function is not taking its address.
As Walter pointed out, you can use refs in BetterC (and of course C++) directly, but I don't see why it cannot be automatically applied to C in general.
1. Why do functions need to be annotated with @safe and nothrow in betterC? Why not make them default? I understand making it default for non-betterC might break some code.
2. string type was uniform and awesome until it was treated as Unicode. Any plans to fix this and remove auto decoding? That would be awesome.
Edit: three questions to two. I had another question about using threads in betterC. But looks like we can't use D threads as they are runtime dependent.
2. I think you're referring to autodecode. There is an effort ongoing to extricate us from that, but it's difficult while maintaining backwards compatibility.
3. That's right. You'll have to use C threads.
See their Oral Histories collection: https://www.computerhistory.org/collections/oralhistories/
We've got a paper on the history of D accepted into this year's History Of Programming Languages (HOPL), which makes us very proud. Andrei, Mike and myself spent a lot of time combing through old emails and n.g. postings to develop an accurate timeline of when and how things came about and from whom.
I was really looking forward to the HOPL conference in London in June to present the paper, but CV scuttled that.
Is "Better C" Done? Or are there any features/changes being planned? Will it always stay backward compatible?
What is your vision for D/betterC/SafeD?
Is the intention at the moment to stay as a systems programming language only, or is your vision that D or betterC or SafeD gain traction as an embedded target language?
I definitely think the focus on correctness and the ease of unit testing would be great in the embedded development space.
What's the story in terms of using existing C (or C++) code with BetterC or D in general?
I'd pick up a comprehensive book like Ali Cehreli's "Programming in D",
https://www.amazon.com/Programming-Tutorial-Reference-Ali-Ce...
and come hang out in the D forums:
You can mix and match C and D code easily in the same program, and to a lesser extent C++ code. This means a larger project can be incrementally converted to D while keeping it running and shipping.
- what is the status of the ecosystem now?
- what are the big issues that make d less appealing?
- ms alexandrescu is still involved in the project?
- where do you see the language in 2 years for now?
I've used it myself to easily convert some of my older C programs to D and make them easier to maintain.
* Regarding the syntax of 'lazy'. It seems to me that it would make for better readability if the lazy keyword were required at the callsite, along the lines of doStuff(lazy getValueUsingExpensiveComputation()); rather than the current syntax where it's not clear at the callsite which, if any, of the arguments are lazy. C# does something similar with ref. What's the thinking behind D's syntax?
* What's the state, and future, of precise garbage collection in D?
Mainly that it be easy and quick for those familiar with C and C++ to get up to speed. With C, C++, and D, you cannot really know what will happen with the argument without looking at the corresponding parameter declaration.
And are there any languages where lazy is not a failure in your opinion?
Edit: removed link to wrong swift feature proposal.
It's a big boon that existing C projects can migrate one object file at a time to betterC, without needing to pull in extra dependencies. Moreover, embedded dev is where C is still the most entrenched due to its runtime simplicity (simple ctr0, linker script, and you're off).