new std.variant (was Re: The Right Approach to Exceptions)

[Robert Jacques]

On Wed, 22 Feb 2012 11:33:57 -0600, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:
> On Wednesday, February 22, 2012 08:19:38 Robert Jacques wrote:
>> To Variant? Yes, definitely. To Appender? I don't think so. There is an
>> slight change in API behavior necessitated by performance  
>> considerations,
>> but I don't think it warrants a review by the community at large.
>> Specifically, appender's internal data structure is now sealed, which  
>> means
>> that .data must always make a copy. My preference would be to deprecate
>> .data in favor of a .dup/.idup pair. It'll break a bunch of code (which  
>> I
>> don't like), but it will make sure no one is calling .data twice in a  
>> row,
>> resulting in a silent performance problem.
>
> I've definitely written code that needed to get at data while appending.  
> I
> would consider it to be a huge downside to not be able to efficiently  
> get at the
> current state of the array within the appender. Why on earth would you  
> seal
> it?
>
> - Jonathan M Davis

There's a big difference between sealed and not accessible. .data's API  
requires exposing an array, and there's no way to do this without leaking  
memory like a sieve in one way or another. However, if all you need is to  
iterate the contents, that's easy to do. I'm currently adding backwards  
iteration. Even indexing is fairly efficient (not yet implemented),  
particularly relative indexing (i.e. n from back or front).

I haven't seen too many use cases yet where accessing the underlying array  
is important, nor has it come up on bugzilla. I've found one case in  
Phobos where appender was used as a stack. What's your example? What  
features does it have to support and how efficient does it have to be?