On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov [ZombineDev] wrote:
2. However, there's this long list of things that you have to avoid.

There's like 10 things to avoid in the language itself: http://dlang.org/spec/garbage.html#op_involving_gc

and most of them are obviously array stuff so it is easy to remember - and easy to skip with a simple array helper... which is often a useful optimization too, make one that uses stack space! You can write one in about 15 minutes.


Now, @nogc is a bit more restrictive since it isn't just avoiding GC calls.... it avoids the *possibility* of GC calls. Even if it would only actually run one in a million times at which point you want the program to die anyway.... @nogc still bans it. Even if it would never actually run, but some leaf function somewhere wrote `int getLength() { return _length; }` instead of `int getLength() @nogc pure const @safe nothrow { return _length; }`... it obviously doesn't run the gc, but still fails @nogc for its entire call tree.


This is why I consider @nogc to be an *extremely* niche feature and generally harmful. It makes things look a lot harder than it really is - people confuse `@nogc` with "no gc". Instead, I suggest just minding the list and using runtime profiling and debugging to ensure your needs are met in actual practice.

3. So while this "@nogc" is technically possible you loose so much of the language that you're better of with C++ (where e.g. "cout" just works*).

of course you could always `printf` lol.

The reason writeln fails @nogc is that it *might* throw an exception with most args if stdout is closed or something.

Perfect example of an *extremely* rare case failing @nogc's ridiculously strict requirements.

Reply via email to