DIP 1008 Preliminary Review Round 1

[Stanislav Blinov via Digitalmars-d]

On Saturday, 20 May 2017 at 02:25:45 UTC, Walter Bright wrote:

> We'll be doing more invisible special casing in the future. For 
> example,
>
>   void foo(scope string s);
>   ...
>   string s;
>   ...
>   foo(s ~ "abc");
>
> This array concatenation does not need to be done with the GC. 
> It's not fundamentally different from what the compiler does 
> now with:
>
>   s = "abc" ~ "def";
>
> not doing a GC allocation, either.

string s = callCAPIAndAllocateString();
foo(s ~ "abc");

What will happen? The compiler will generate different code? 
Won't compile? The former means invisible performance gap. The 
latter means an unpleasant surprise. Neither are good. Do we 
really need such special cases?

> The compiler also detects when it can allocate a closure on the 
> stack rather than on the GC. We expect the compiler to do such 
> transformations.

You're saying "detects" as if it always does that, which is not 
true. And this avoids the issue, not addresses it. We have *no* 
control over how the closure is allocated. It's either none, or 
GC. Which means we can't have dynamically-allocated closures in 
@nogc code. Which forces user to write verbose code (i.e. structs 
with opCall), losing the benefit of anonymous functions 
altogether.

> In general, if the compiler can determine the lifetime of an 
> allocation, and can control "leakage" of any references to that 
> allocation, then it is fair game to not use the GC for it.

*If*. And if it can't, it won't compile. Which is:
a) Frustrating when it should've detected it.
b) Makes you think of allocating things manually from the start, 
to not deal with sudden failure to compile.

> The recent 'scope' improvements have uncovered a lot more 
> opportunities for this, and DIP 1008 is the first fruit of it.

That is true, benefits of 'scope' are indeed huge. But please, 
consider how fragile all the "special-casing" is. It's based on 
preconditions and assumptions made by the compiler, and is beyond 
user control. It hides potential maintenance problems.