DIP25 draft available for destruction

[Rob T]

On Thursday, 7 February 2013 at 05:37:44 UTC, Rob T wrote:
> On Wednesday, 6 February 2013 at 22:14:42 UTC, Andrei 
> Alexandrescu wrote:
>> On 2/6/13 5:05 PM, Timon Gehr wrote:
>>> On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:
>>>> It would be more consistent with C++, but less so with the 
>>>> notion of
>>>> safety. I find it very consistent that all uses of 
>>>> &expression are safe,
>>>> and this is the kind of consistency Walter and I believe is 
>>>> worth aiming
>>>> for.
>>>>
>>>
>>> So you are saying this should compile?:
>>>
>>> struct S{
>>> int x;
>>> int foo()@safe{ return x; }
>>> }
>>>
>>> int delegate()@safe foo()@safe{
>>> S s;
>>> return &s.foo;
>>> }
>>
>> Yah, it should, and it also should detect the escape and 
>> allocate foo's frame on the heap.
>>
>> Andrei
>
> I thought we wanted to minimize allocations, especially silent 
> ones. In the quoted example, I'd rather the address taking be 
> disallowed at compile time unless the programmer explicitly 
> allocated S on the heap.
>
> --rt

In other words @safe should explicitly mean "I hereby verify that 
the code is safe" not "I will silently re-write your code in 
unknown ways to make it safe".

PLEASE reconsider!

--rt