DIP60: @nogc attribute

[via Digitalmars-d]

On Thursday, 17 April 2014 at 08:22:32 UTC, Paulo Pinto wrote:
> Of course it was sold at WWDC as "ARC is better than GC" and 
> not as "ARC is better than the crappy GC implementation we have 
> done".

I have never seen a single instance of a GC based system doing 
anything smooth in the realm of audio/visual real time 
performance without being backed by a non-GC engine.

You can get decent performance from GC backed languages on the 
higher level constructs on top of a low level engine. IMHO the 
same goes for ARC. ARC is a bit more predictable than GC. GC is a 
bit more convenient and less predictable.

I think D has something to learn from this:

1. Support for manual memory management is important for low 
level engines.

2. Support for automatic memory management is important for high 
level code on top of that.

The D community is torn because there is some idea that libraries 
should assume point 2 above and then be retrofitted to point 1. I 
am not sure if that will work out.

Maybe it is better to just say that structs are bound to manual 
memory management and classes are bound to automatic memory 
management.

Use structs for low level stuff with manual memory management.
Use classes for high level stuff with automatic memory management.

Then add language support for "union-based inheritance" in 
structs with a special construct for programmer-specified subtype 
identification.

That is at least conceptually easy to grasp and the type system 
can more easily safeguard code than in a mixed model.

Most successful frameworks that allow high-level programming have 
two layers:
- Python/heavy duty c libraries
- Javascript/browser engine
- Objective-C/C and Cocoa / Core Foundation
- ActionScript / c engine

etc

I personally favour the more integrated approach that D appears 
to be aiming for, but I am somehow starting to feel that for most 
programmers that model is going to be difficult to grasp in real 
projects, conceptually. Because they don't really want the low 
level stuff. And they don't want to have their high level code 
bastardized by low level requirements.

As far as I am concerned D could just focus on the structs and 
the low level stuff, and then later try to work in the high level 
stuff. There is no efficient GC in sight and the language has not 
been designed for it either.

ARC with whole-program optimization fits better into the 
low-level paradigm than GC. So if you start from low-level 
programming and work your way up to high-level programming then 
ARC is a better fit.

Ola.