On 10/17/2012 10:15 PM, sclytrack wrote:
> On Wednesday, 17 October 2012 at 19:46:51 UTC, bearophile wrote:
>> sclytrack:
>>
>>> It doesn't give an error when marking the function with safe.
>>>
>>> @safe
>>> int[] create()
>>> {
>>> }
>>
>> I think marking it @safe is not relevant. In theory a good type system
>> should give an error message on similar code. I don't know if D is
>> supposed to spot similar error situations.
>>
>> Bye,
>> bearophile
>
> If that's the case then they should call it safeR D instead of safe D.

I think what he meant to say was that it should be illegal to do this
even in @system code, not that it is OK that it passes with @safe.

On Wednesday, 17 October 2012 at 20:38:03 UTC, bearophile wrote:
> Jonathan M Davis:
>
>>there's no way for the compiler to always catch it for you.<
>
> I think there are type systems able to always catch this kind of bug (conservative region analysis, it means that if it can't demonstrate the memory doesn't escape, it prudently refuses the code). D doesn't have such kind of type system.
>
> Bye,
> bearophile

Hi, sorry, I didn't see this thread earlier.

I'm new with the D-Language, but very interested.

My opinion is, that this behaviour mustn't be allowed with any modern compiler.

The solution isn't as complicated as it looks on first hand: The compiler will just have to test, if a return-value has got an address on the stack of the function, what shall just even be closed.

The actual code doesn't calculate any pointer addresses by hand. The address is on the stack, because of the declaration of a1. b1 takes over this address and therefor there must be a flag in the symboltable, indicating it mustn't be used for return-value. This doesn't have to do anything with safe or pure. It's an error in any code.

Think of the following: What will happen with a2, when for example a2 will be given a new value? It's actual address points on a deprecated address on stack.

The resulting runtime errors one can just imagine.

Hi,
I'm new to D and stumbled upon this very interesting discussion.
My question now is:
can you provide an example of how to return a collection of
homogeneous elements whose size is not known at compile time (for
wich you would normally use a dynamic array) from a function?

Thanks,
Marco

On Saturday, 14 June 2014 at 14:02:52 UTC, Marco Cosentino wrote:
> Hi,
> I'm new to D and stumbled upon this very interesting discussion.
> My question now is:
> can you provide an example of how to return a collection of
> homogeneous elements whose size is not known at compile time (for
> wich you would normally use a dynamic array) from a function?

    int[] foo() {
        int[] data = [1,2,3,4];    // create new array on the heap
        data ~= [5,6,7,8];         // append some data
        return data;
    }

The problem with the OP's code was not per se that he returned a slice, but that he took this slice from a fixed-length local array. The example above doesn't do that, and is therefore safe.

>         int[] data = [1,2,3,4];    // create new array on the heap

Thanks for the answer.
This is the bit of information I was missing: how to create an
array in the heap.
Is also this a valid way to do so?

int[] data = new int[0];
data ~= [4,2,3,1];

On Saturday, 14 June 2014 at 21:37:51 UTC, Marco Cosentino wrote:
>>        int[] data = [1,2,3,4];    // create new array on the heap
>
> Thanks for the answer.
> This is the bit of information I was missing: how to create an
> array in the heap.
> Is also this a valid way to do so?
>
> int[] data = new int[0];
> data ~= [4,2,3,1];

Simply "int[] = [4,2,3,1];" will do. Arrays are always created on the heap by default. To override that, you can assign to a static array, which resides on the the stack. Then you slice your static array.