On 2014-04-23 04:33:00 +0000, Walter Bright <[email protected]> said:
On 4/22/2014 12:42 PM, Michel Fortin wrote:
On 2014-04-22 19:02:05 +0000, Walter Bright <[email protected]> said:
Memory safety is not a strawman. It's a critical feature for a modern
language, and will become ever more important.
What you don't seem to get is that ARC, by itself, is memory-safe.
I repeatedly said that it is not memory safe because you must employ
escapes from it to get performance.
It wasn't that clear to me you were saying that, but now it makes sense.
In Objective-C, the performance-sensitive parts are going to be
implemented in C, that's true. But that's rarely going to be more than
5% of your code, and probably only a few isolated parts where you're
using preallocated memory blocks retained by ARC while you're playing
with the content.
If you're writing something that can't tolerate a GC pause, then it
makes perfect sense to make this performance-critical code unsafe so
you can write the remaining 95% of your app in a memory-safe
environment with no GC pause.
D on the other hand forces you to have those GC pauses or have no
memory management at all. It's a different tradeoff and it isn't
suitable everywhere, but I acknowledge it makes it easier to make
performance-sensitive code @safe, something that'd be a shame to lose.
Objective-C isn't memory safe because it lets you play with raw
pointers too. If
you limit yourself to ARC-managed pointers (and avoid undefined behaviours
inherited from C) everything is perfectly memory safe.
Allow me to make it clear that IF you never convert an ARC reference to
a raw pointer in userland, I agree that it is memory safe. But this is
not practical for high performance code.
Framing the problem this way makes it easier to find a solution.
I wonder, would it be acceptable if ARC was used everywhere by default
but could easily be disabled inside performance-sensitive code by
allowing the user choose between safe GC-based memory management or
unsafe manual memory management? I have an idea that'd permit just
that. Perhaps I should write a DIP about it.
I'm pretty confident that had I continued my work on D/Objective-C we'd now be
able to interact with Objective-C objects using ARC in @safe code. I was
planning for that. Objective-C actually isn't very far from memory safety now
that it has ARC, it just lacks the @safe attribute to enable compiler
verification.
I wish you would continue that work!
I wish I had the time too.
--
Michel Fortin
[email protected]
http://michelf.ca
