The "no gc" crowd

[Adam D. Ruppe]

On Tuesday, 8 October 2013 at 17:00:35 UTC, Dicebot wrote:
> Imagine stuff like vibe.d - for proper performance you don't 
> want to make any allocations during request handling.

That brings up another interesting advantage to my extensible 
scheme: we could also define @blocking in the library to put on 
I/O calls and then vibe.d does a check for it and complains if 
you called one.

Though getting this kind of coverage would be hard, a third party 
lib might not use it and then the custom check would miss the 
problem. But, in general, I'm sure if we had the capability, uses 
would come up beyond nogc/noheap.

> I have said on this topic several times - it does not matter 
> what is _possible_ to do with D memory model. It does matter 
> what is _convenient_ to do.

And, of course, "my function didn't compile because phobos uses 
the gc" is hardly convenient unless phobos offers the 
functionality (where possible) without allocating. I think output 
ranges offer a pretty good solution here for a lot of cases, and 
could be added without breaking the current interfaces - just 
keep functions that return new strings as alternatives 
implemented in terms of the base output range function.