Ranges require GC?

[Frustrated]

On Wednesday, 11 December 2013 at 02:37:32 UTC, Jonathan M Davis 
wrote:
> On Wednesday, December 11, 2013 03:09:52 Frustrated wrote:
>> But surely memory gets allocated in some way?
>> 
>> In Programming in D:
>> 
>> "For example filter(), which
>> chooses elements that are greater than 10 in the following 
>> code,
>> actually returns a range
>> object, not an array:"
>> 
>> But if filter is a range and returns an object then how is that
>> object allocated?
>
> It's on the stack. filter returns a struct whose only member is 
> the range that
> was passed to it. The lambda that you pass to filter might be 
> allocated on the
> heap under some circumstances, but that's the only risk of heap 
> allocation
> with filter, and if you use a function rather than a lambda 
> literal or a
> delegate, then you definitely don't get any heap allocation 
> (and I don't think
> that it's even the case that you necessarily get a heap 
> allocation with a
> lambda).
>
> Most ranges in Phobos are very lightweight, because they just 
> wrap another
> range and maybe add a member variable or two to handle what 
> they do (and many
> don't even need that). And if the optimizer does a decent job, 
> then most of
> the wrappers even get optimized away, causing very little 
> overhead at all
> (though I'm sure that dmd can be improved in that regard).
>
> Whether any particular range allocates anything on the heap 
> depends on the
> range, but it's likely to be very rare that they will - 
> particularly in
> Phobos.
>
> - Jonathan M Davis

I'm trying to avoid the GC so knowing whether or not ranges will 
use the heap is extremely important. I guess that is where the 
@nogc attribute that everyone talks about would come in very 
handy.