RFC, ensureHeaped

[Steven Schveighoffer]

On Sat, 13 Nov 2010 16:09:32 -0500, spir <denis.spir at gmail.com> wrote:

> On Sat, 13 Nov 2010 13:19:25 -0500
> bearophile <bearophileHUGS at lycos.com> wrote:
>
>> Steven Schveighoffer:
>>
>> > Then you just wasted time duping that argument.  Instead of a  
>> defensive
>> > dup, what if we had a function ensureHeaped (better name suggestions?)
>>
>> I have created a bug report to avoid this whole pair of threads to be  
>> lost in the dusts of time:
>> http://d.puremagic.com/issues/show_bug.cgi?id=5212
>>
>> Feel free to add a note about your ensureHeaped() idea at the end of  
>> that enhancement request :-)
>>
>> (To that enhancement request I have not added my idea of the @onheap  
>> attribute because I think it's too much complex to implement according  
>> to the design style of the D compiler).
>>
>> Bye,
>> bearophile
>
> I was the one bitten by the bug. I think it's really a naughty feature,  
> was about to create a bug entry when saw Bearophile's post. In my  
> opinion, if
> 	void f(int[] ints) {doWhateverWith(ints);}
> works, then
> 	void f(int[] ints...) {doWhateverWith(ints);}
> must just work as well.

I don't really agree.  The ... version is optimized so you can pass  
typesafe variadic args.  If the compiler would generate a heap allocation  
for that, then you may be wasting a lot of heap allocations.  One thing  
you may learn in D is that heap allocation == crappy performance.  The  
less you allocate the faster your code gets.  It's one of the main reasons  
Tango is so damned fast.  To have the language continually working against  
that goal is going to great for inexperienced programmers but hell for  
people trying to squeeze performance out of it.

I think what we need however, is a way to specify intentions inside the  
function.  If you intend to escape this data, then the runtime/compiler  
should make it easy to avoid re-duping something.

> I consider variadic args as just syntactic honey for clients of a func,  
> type, lib. There should be no visible semantic difference, even less  
> bugs (and certainly not segfault when the code does not manually play  
> with memory!). But I may have wrong expectations about this feature in  
> D, due to how variadics work in other languages I have used.
>
> It was hard to debug even with the help of 3 experienced D programmers.

To be fair, it was easy to spot when you gave us the pertinent code :)

-Steve