> There are a couple of points:
> 1) ruby-ffi releases are timed to coincide with JRuby releases, to
> keep the FFI apis in sync.  This means it takes on average 3 months
> from one 0.x.0 release to the next, which can seem like an eternity to
> someone waiting for a feature.
> 
> 2) The more stuff added to the core api, the more other
> implementations have to implement.
> 
> Putting these extras in NiceFFI or another gem allows the features to
> iterate a lot quicker, since they no longer impose any api
> compatibility constraints - its all pure ruby that runs on any FFI
> implementation.

I see your challenge, and while I like the ability to quickly deliver new features, having FFI::Reference feels more fundamental and core-ish than the "nice to have" extras in NiceFFI.  It's similar to one of the things that bugs me about the Inno installer...you have to download and and install a completely different package to get the compiler's pre-processor :(  It's so useful that it should be part of the base package.

Since FFI::Reference addresses some pretty common C usages, I'm for including in FFI core especially as you mentioned it can be implemented in pure Ruby.

That said, do the other implementations think it will be overly burdensome to implement?

Jon