On 4/21/2014 1:29 PM, Steven Schveighoffer wrote:
I think you are misunderstanding something. This is not for a pervasive
ARC-only, statically guaranteed system. The best example he gives (and I agree
with him) is iOS. Just look at the success of iOS, where the entire OS API is
based on ARC (actually RC, with an option for both ARC and manual, but the
latter is going away). If ARC was "so bad", the iOS experience would show it.
You may have doubts, but I can assure you I can build very robust and performant
code with ARC in iOS.
The thing is, with iOS ARC, it cannot be statically guaranteed to be memory
safe. This makes it simply not acceptable for D in the general case. It "works"
with iOS because iOS allows all kinds of (unsafe) ways to escape it, and it must
offer those ways because it is not performant.
Kinda sorta memory safe, mostly memory safe, etc., is not a static guarantee.
There is JUST NO WAY that:
struct RefCount {
T* data;
int* count;
}
is going to be near as performant as:
T*
1. A dereference requires two indirections. Cache performance, poof!
2. A copy requires two indirections to inc, two indirections to dec, and an
exception unwind handler for dec.
3. Those two word structs add to memory consumption.
As you pointed out, performant code is going to have to cache the data* value.
That cannot be guaranteed memory safe.
I can't reconcile agreeing that ARC isn't good enough to be pervasive with
compiler technology eliminates unnecessary ARC overhead.
It's pretty pervasive on iOS. ARC has been around since iOS 4.3 (circa 2011).
Pervasive means "for all pointers". This is not true of iOS. It's fine for iOS
to do a half job of it, because the language makes no pretensions about memory
safety. It is not fine for D to replace a guaranteed memory safe system with an
unsafe, hope-your-programmers-get-it-right, solution.
