TempAlloc Overhaul

[Daniel Gibson]

Am 17.06.2011 19:59, schrieb Jose Armando Garcia:
> On Fri, Jun 17, 2011 at 2:40 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> On 6/17/11 11:50 AM, Jose Armando Garcia wrote:
>>> On Fri, Jun 17, 2011 at 11:12 AM, dsimcha<dsimcha at yahoo.com>  wrote:
>>>> On 6/16/2011 11:46 PM, Andrei Alexandrescu wrote:
>>>>> * newArray ->  "For performance reasons, the returned array is not
>>>>> initialized." Then call it newUninitializedArray. Make safety the
>>>>> default and lack thereof the verbose alternative.
>>>>
>>>> Here I'm going to have to strongly disagree with you.  The whole point of
>>>> TempAlloc is that it's a performance hack.  In general I agree it's
>>>> better
>>>> to do the safe thing by default, but libraries specifically written as
>>>> performance hacks are an exception.  In TempAlloc it makes sense to do
>>>> the
>>>> efficient thing by default.  I personally would never use newArray as
>>>> opposed to newUninitializedArray and TempAlloc.newUninitializedArray (31
>>>> characters) feels **ridiculously** verbose and would clutter the API.
>>>
>>> Hmm. If this is a hack then what is it doing in the std library for
>>> the language?!
>>
>> For speed purposes. We're trying to minimize patently unsafe constructs in
>> the language proper, but I see nothing wrong with having library artifacts
>> that sacrifice safety for speed when the gain is significant.
> 
> Hmm. I don't know. Maybe we can create an internal package
> (std.internal) that std modules can use in their implementation. The
> daring programmer can also use if they dig around but maybe we
> shouldn't put the gun on the kitchen counter. Modules in std.internal
> should be ddoc but they are not linked from
> d-programming-language.org.
> 
> This is also in reply to bearophile's comment.
> 
> -Jose

I think it's a bad idea to not link documentation on
d-programming-language.org just because its about a "unsafe" feature.. D
is a system programming language after all.
If we want to "hide" unsafe parts of the language or library we should
as well remove the documentation for the std.c bindings, the
documentation on pointers, ...

Cheers,
- Daniel