DIP60: @nogc attribute

[Michel Fortin via Digitalmars-d]

On 2014-04-18 20:40:06 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> O-C doesn't use ARC for all pointers, nor is it memory safe.

@safe would be very easy to implement in Objective-C now that ARC is there.

This has got me thinking. Ever heard "C is the new assembly"? I think 
this describes very well the relation between C and Objective-C in most 
Objective-C programs today.

Objective-C enables ARC by default for all pointers to Objective-C 
objects. Since virtually all Objective-C APIs deal with Objective-C 
objects (or integral values), if you limit yourself to Objective-C APIs 
you're pretty much memory-safe.

When most people write Objective-C programs, they use exclusively 
Objective-C APIs (that deal with Objective-C objects and integrals, 
thus memory-safe), except for the few places where performance is 
important (tight loops, specialized data structures) or where 
Objective-C APIs are not available.

You can mix and match C and Objective-C code, so no clear boundary 
separates the two, but that doesn't mean there couldn't be one. Adding 
a @safe function attribute to Objective-C that'd prevent you from 
touching a non-managed pointer is clearly something I'd like to see in 
Objective-C. Most Objective-C code I know could already be labeled 
@safe with no change. Only a small fraction would have to be updated or 
left unsafe.

Silly me, here I am discussing a improvement proposal for Objective-C 
in a D forum!

The point being, D could have managed and unmanaged pointers (like 
Objective-C with ARC has), make managed pointers the default, and let 
people escape pointer management if they want to inside 
@system/@trusted functions. One way it could be done is by tagging 
specific pointers with some attribute to make them explicitly not 
managed (what __unsafe_unretained is for in Objective-C). Perhaps the 
whole function could be tagged too. But you won't need this in general, 
only when optimizing a tight loop or something similar where 
performance really counts.

Whether that's the path D should take, I don't know.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca