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.
