On Tuesday, 8 October 2013 at 17:47:54 UTC, Brad Anderson wrote:
On Tuesday, 8 October 2013 at 16:29:38 UTC, ponce wrote:
On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
It is not overblown. It is simply "@nogc" which is lacking
but absolutely mandatory. Amount of hidden language
allocations makes manually cleaning code of those via runtime
asserts completely unreasonable for real project.
Hidden language allocations:
- concatenation operator ~
- homogeneous arguments void (T[]... args)
- "real" closures that escapes
- array literals
- some phobos calls
What else am I missing?
I don't see the big problem, and a small frac
tion of projects
will require a complete ban on GC allocation, right?
Johannes Pfau's -vgc pull request[1] had a list of ones he was
able to find. It's all allocations, not just hidden allocations:
COV // Code coverage enabled
NEW // User called new (and it's not placement new)
ASSERT_USER // A call to assert. This usually throws, but can
be overwritten
// by user
SWITCH_USER // Called on switch error. This usually throws, but
can be
// overwritten by user
HIDDEN_USER // Called on hidden function error. This usually
throws, but can
// be overwritten by user
CONCAT // a ~ b
ARRAY // array.length = value, literal, .dup, .idup, .sort
APPEND // a~= b
AALITERAL // ["a":1]
CLOSURE
1. https://github.com/D-Programming-Language/dmd/pull/1886
The closure one is a problem. I think that returning a closure
should use a different syntax from using a normal delegate. I
doubt it's something you _ever_ want to do by accident.
It's a problem because you can't see at a glance if a function
uses a closure or not. You have to inspect the entire function
very carefully, checking all
code paths.
