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.
