DIP60: @nogc attribute

[Michel Fortin via Digitalmars-d]

On 2014-04-23 04:33:00 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 4/22/2014 12:42 PM, Michel Fortin wrote:
>> On 2014-04-22 19:02:05 +0000, Walter Bright <newshound2 at digitalmars.com> 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
michel.fortin at michelf.ca
http://michelf.ca