I am not expert in such things, but here are few comments and
questions.
Errors for scope violations are only reported in @safe code.
This seems acceptable only if the compiler switch "-scope"
implies functions to be @safe by default and @system on request,
because currently lot of D programmers don't apply annotations
like @safe to their D code. Opt-in safety doesn't work well (and
in D we still have the problems caused by null pointers and
references).
- - - - - - - - - -
Also consider an annotation like "!scope" or "@escape" for the
opposite purpose.
- - - - - - - - - -
Delegates currently defensively allocate closures with the GC.
Few actually escape, and with scope only those that actually
escape need to have the closures allocated.<
So there's no need for extra annotations to make delegates @nogc
in most cases?
- - - - - - - - - -
Regarding array literals, some people proposed a syntax for
fixed-size arrays to avoid heap-allocations (the "s" after the
array literal):
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
Is DIP69 able to infer those arrays can be both stack-allocated?
Is the "s" annotations still useful?
- - - - - - - - - -
Regarding the benefits, is escape analysis going to be used to
allocate _automatically_ some small dynamic arrays and
classes/structs on the stack instead of heap?
And is escape analysis going to automatically give hints to the
GC to deallocate faster GC-allocated memory that doesn't escape?
void foo() {
// Both dynamic arrays don't escape foo
// Automatically stack allocated.
auto a = new int[3];
// Heap-allocated but deterministically
// deleted at the end of foo scope.
auto b = new int[10_000];
}
- - - - - - - - - -
Bye,
bearophile
