Variable-length stack allocated arrays

[grauzone]

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> grauzone wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> grauzone wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> The idea is that the API offers a means to define and use 
>>>>>>> temporary buffers without compromising memory safety. Even if you 
>>>>>>> escape data allocated via getBuffer that persists after 
>>>>>>> releaseBuffer, that will not cause undefined behavior. (It may, 
>>>>>>> however, cause data to be overwritten because another call to 
>>>>>>> getBuffer will reuse memory.) Leaks are also possible if you 
>>>>>>> don't release the buffer. That can be solved by not offering 
>>>>>>> getBuffer and releaseBuffer as they are, but instead only 
>>>>>>> encapsulated in a struct with the appropriate constructor and 
>>>>>>> destructor.
>>>>>>
>>>>>> That's an interesting point. You can have two things:
>>>>>> 1. Correct memory managment (one can never access an object that's 
>>>>>> supposed to be free'd)
>>>>>> 2. Safe memory managment (event if you access an object that's 
>>>>>> supposed to be free'd, it's memory safe)
>>>>>>
>>>>>> In safe mode, 1. can't be allowed, and 2. is better than nothing. 
>>>>>> In normal D, I'd say 2. is quite useless, except as an debugging 
>>>>>> option.
>>>>>
>>>>> Normal D must be debuggable D.
>>>>
>>>> That isn't the case right now and never will be.
>>>
>>> Then if I were you and I really believed that, I wouldn't waste one 
>>> more minute hanging out in this group.
>>
>> Don't worry, I won't leave so easily.
> 
> I know. Clearly there is something in D that you find irresistibly 
> attractive; I wonder what that is :o).

It's like a narcotic drug.

>> That said, if you use "delete" (or GC.free) incorrectly, you may end 
>> up with an undebuggable program. Plus there's no way manual free will 
>> ever be removed from D. I'm sure you know that, but it sounds like 
>> you're denying that. Whatever.
> 
> Of course I'm denying it because it's false. SafeD will not allow 
> programs containing manual free. And SafeD is quickly becoming a 
> reality, your pessimism notwithstanding.

Does this imply you'Re going to make SafeD default, and discourage use 
of "unsafe" D?

> 
> Andrei