On 4/1/2017 7:54 AM, deadalnix wrote:
The problem you want to address is not GC allocations, it is GC collection cycles. If everything is freed, then there is no GC problem. not only this, but this is the only way GC and nogc code will interact with each others.
This does not address the stated need (by many programmers) to not even have to link in the GC code. A solution that falls short of this will be rejected. The rejections may not be technically well founded, but we're not in a good position to try to educate the masses on this. A solution that does not require linking to the GC sidesteps that problem.
As long as a memory allocation has an owner the compiler can track, it can be freed explicitly, and, when it cannot, the compiler transfer ownership to the GC, which is illegal in @nogc code. Transfering the ownership to the unwind handler when doing: throw new FooException(); Is not rocket science and doesn't need any new language addition.
There's also: auto e = someFunctionThatReturnsAnException(); throw e; where who owns it or how it was allocated is not clear at all. Other issues that need attention are: 1. chaining exceptions 2. rethrowing
Now onto to scope. Scope essentially means that you are going to use some object without taking ownership of it. Indeed, in case of catch(Exception e) the language has to transfers the ownership of the Exception to the GC, which is the thing that should be illegal (not throwing). catch(scope Exception e) would work both with GC owned and runtime owned exception, and, because the runtime know what's up, it can explicitly free the exception when it exit the catch block (there is already a runtime call for that), in the case it owns it.
'scope' is indeed a critical factor in making this work.
It doesn't need any kind of throw new scope Exception, and was proposed, literally, years ago during discussion around DIP25 and alike. I urge you to reconsider the proposal that were made at the time. They solve all the problems you are discovering now, and more. And, while more complex that DIP25 alone, considering DIP25+DIP1000+this thing+the RC object thing, you are already in the zone where the "simple" approach is not so simple already.
I did some searching for this previous proposal discussion, but could not find it. Instead, I'll go by your description of it here.
I've written a more fleshed out proposal and started a new thread with it. Feel free to rip it to shreds!
