DIP60: @nogc attribute

[Michel Fortin via Digitalmars-d]

On 2014-04-18 23:48:43 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 4/18/2014 3:02 PM, Michel Fortin wrote:
>> 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.
> 
> "pretty much" isn't really what we're trying to achieve with @safe.

A lot of D code is memory safe too, but not all. Is D memory-safe? Yes, 
if you limit yourself to the @safe subset (and avoid the few holes 
remaining in it). Same thing for Objective-C: there exists a subset of 
the language that is memory safe, and pretty much everyone limit itself 
to that subset already, unless there's a reason to go lower-level and 
use C.

In other words, unmanaged pointers are the assembler of Objective-C. 
It's unsafe and error prone, but it lets you optimize things when the 
need arise.


>> 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.
> 
> Yeah, it could, and the design of D has tried really hard to avoid 
> such. "Managed C++" was a colossal failure.
> 
> I've dealt with systems with multiple pointer types before (16 bit X86) 
> and I was really, really happy to leave that **** behind.

Yet, there's C++ and its proliferation of library-implemented managed 
pointer types (shared_ptr, unique_ptr, weak_ptr, scoped_ptr, and 
various equivalents in libraries). Whether they're a success or a patch 
for shortcomings in the language, they're used everywhere despite the 
various mutually incompatible forms and being all leaky and arcane to 
use.

And if I'm not mistaken, this is where the @nogc subset of D is headed. 
Already, and with good reason, people are suggesting using library 
managed pointers (such as RefCounted) as a substitute to raw pointers 
in @nogc code. That doesn't automatically make @nogc a failure — C++ is 
a success after all — but it shows that you can't live in a modern 
world without managed pointers. If multiple pointer types really dooms 
a language (your theory) then the @nogc D subset is doomed too.

Yet, ARC-managed pointers are a huge success in Objective-C. I think 
the trick is to not bother people with various pointer types in regular 
code. Just make sure the default pointer type works everywhere in 
higher-level code, and then provide clear ways to escape that 
management and work at a lower level when you need to optimize a 
function or interface with external C code.

D thrives with raw pointers only because its GC implementation happens 
to manage raw pointers. That's a brillant idea that makes things 
simpler, but this also compromises performance at other levels. I don't 
think there is a way out of that performance issue keeping raw pointers 
the default, even though I'd like to be proven wrong.

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