Exceptions in @nogc code

[deadalnix via Digitalmars-d]

On Tuesday, 4 April 2017 at 09:45:14 UTC, Walter Bright wrote:
> 1. we already have some of the benefits of the proposal because 
> D has transitive immutability
>

This works hand in hand with D type qualifier system.

> 2. I'm looking for a solution where exceptions don't rely on 
> the GC to the point where the GC code doesn't even need to be 
> linked in. This proposal appears to maintain a dependence on 
> the GC.
>

Then just do:
auto ePtr = malloc(...);
auto e = *(cast(Exception*) &ePtr);
throw e;

Problem solved, you did not used the GC.

This proposal has nothing to do with Exceptions. It just happens 
to solve the Exception problem, just as it does for many others.

The problem people have with the GC isn't that it need to be 
linked in, it is that collection cycles create latency that 
doesn't work for their use case. If allocation are freed, then 
there is no GC problem.

Nobody is complaining that they cannot use C++ without its 
runtime. And for the 0.1% who actually need it, they just write 
custom allocation, and jump through a few hoops. This is a just 
good engineering. You are trying to solve the wrong problem.

really, in the process you are also murdering another legit use 
case that is orders of magnitude more common: library writers. 
They want to write code that'll work when the GC is used or not.

> 3. It requires annotation of catch declarations with one of "", 
> "scope", or "owned". I expect this would be a significant 
> problem
>

This proposal just add the owned type qualifier. scope already 
exists. It solves many problem for which new syntax have been 
introduced, so it's rather rich.

"I don't want this proposal that add one new syntax, I'd rather 
have 4 smaller proposals that each add a new syntax."

> 4. Since the catch block is not type checked against the 
> corresponding throw, the object will have to have noted in it 
> who owns it.
>

throw never leaks, so there is no point in checking the throw. 
You already throw something that is owned by the GC, in which 
case you leaked earlier, or you transfer the ownership to the 
runtime and you haven't leaked yet.

Because throw never leaks, there is no point in butchering throw 
to make it compatible with nogc.

Back to the catch block, the question is the same as for a 
function call or anything else really. It either borrow the 
exception (scope) take ownership of it (owned) or just delegate 
the work to the GC.

> 5. The normal case is:
>
>     throw new Exception("message");
>     ...
>     catch (Exception e) {
>          writeln(e.msg);
>     }
>
> which would ideally work without involving the GC at all.
>

This cannot be nogc in the general case because e can be 
reassigned to anything that is owned by the GC. In that specific 
case, scope can be inferred.

> 6. reducing the amount of GC garbage created is good, but does 
> not solve the problem of "I don't want to use D because of the 
> GC".
>
> This proposal looks promising for making a better garbage 
> collected language, but people want a language with an optional 
> GC.

If you have guarantee that you won't leak, and so will never run 
collection cycle, you don't have a GC, you effectively have 
malloc and free. There is no need to butcher the language because 
there are morons on the internet. really that's hardly newsworthy.