On Monday, 10 November 2014 at 08:29:40 UTC, Don wrote:
> stack-allocked array (otherwise stack allocated arrays are useless). Eg you should be able to pass a slice of a stack array to writefln().
>
> Detecting if the slice is returned, requires flow analysis. Currently the front-end doesn't do any flow analysis at all, except for a couple of special cases like closures and super() calls.

Ceterum censeo ...
http://wiki.dlang.org/User:Schuetzm/scope

On 11/10/14 3:29 AM, Don wrote:
>
> The problem is, that you need to be able to take a slice of a
> stack-allocked array (otherwise stack allocated arrays are useless). Eg
> you should be able to pass a slice of a stack array to writefln().
>
> Detecting if the slice is returned, requires flow analysis. Currently
> the front-end doesn't do any flow analysis at all, except for a couple
> of special cases like closures and super() calls.

While all of that is true, the OP's code should be rejected. It returns a static array as a dynamic array in one expression.

-Steve

On 09/11/2014 10:34, bearophile wrote:
> If you just disallow that kind of operations indiscriminately, you
> reduce a lot the usefulness of D (because fixed size => dynamic slice
> array is a conversion useful in many cases) and probably force the
> introduction of many casts, and I don't know if this will increase the
> overall safety of the D code.

Seeing as the 'scope' attribute doesn't seem to be happening any time soon, shouldn't the compiler reject static array slicing in @safe code? The user is then forced to think about the operation, and put the code in a @trusted delegate if they think it is actually safe.

<grumble>
It would help a bit if we had @trusted blocks instead of having to call a @trusted delegate inline (which is non-obvious). The status quo encourages people to just mark whole functions as @trusted, skipping much otherwise acceptable safety enforcement.
</grumble>

On Sunday, 9 November 2014 at 10:04:16 UTC, bearophile wrote:
> Yeah, what do you suggest to change in the language to avoid this problem?

1. Deprecate dynamic arrays.

2.  Implement dynamic arrays as a library type with it's own fat-slice implementation which supports reallocation (slices with indirection and stored begin/end indices).

3. Provide conversion to regular shrinkable slices for operations on the array with a warning similar to those provided by iterators in C++.

On 12/11/2014 15:36, Nick Treleaven wrote:
> Seeing as the 'scope' attribute doesn't seem to be happening any time
> soon, shouldn't the compiler reject static array slicing in @safe code?
> The user is then forced to think about the operation, and put the code
> in a @trusted delegate if they think it is actually safe.

This is:
https://issues.dlang.org/show_bug.cgi?id=8838

Apparently it's a bit tricky to implement ATM.

yebblies:

> This is not very easy, because the compiler lowers all static array
> assignment to slice assignment, making _every_ static array assignment
> unsafe.  That needs to be fixed first, and requires extensive changes > in the interpreter.

Steven Schveighoffer:

> Can you just ban slicing that escapes the statement?

"Nick Treleaven"  wrote in message news:m42lbb$2pru$1@digitalmars.com... 

> This is:
> https://issues.dlang.org/show_bug.cgi?id=8838
> 
> Apparently it's a bit tricky to implement ATM.
> 
> yebblies:
> 
>  > This is not very easy, because the compiler lowers all static array
>  > assignment to slice assignment, making _every_ static array assignment
>  > unsafe.  That needs to be fixed first, and requires extensive changes  > in the interpreter.

I think the situation has slightly improved since.