The "no gc" crowd

[Don]

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.