@Christoph: arbitrarily, of course :D Joke aside, it should also use *zip*
for the *(keys, values)* constructor (like Base does).
@tshort:
It can have arbitrary *isbits* & *immutables* as keys.
E.g, this works (should probably get some macro sugar):
*function test{Keys<: Tuple{Val{1}, Val{:c},
Val{MyKeyType()}}(x::FixedKeyValueDict{Keys})*
Also, it doesn't need to look up if a Dict is already defined, which
simplifies the implementation.
In general, I think it's a bit more future proof.
I expect generating types via eval to be never really idiomatic, while*
@generated *seems to be fine for these kind of optimizations.
With *getfield* overloading and better constant propagation, the
implementation might be freed of any *@generated* and macro magic at some
point, which I think is desirable.
For NamedTuples speaks, that it'll be equally fast or faster in most cases
and* getfield/setfield* works currently better with types.
Also, it already has the nicer macro sugar ;)
Am Montag, 11. April 2016 14:08:59 UTC+2 schrieb Simon Danisch:
>
> Here is yet another package: FixedSizeDictionaries.jl
> <https://github.com/SimonDanisch/FixedSizeDictionaries.jl>
>
> From the README:
> *Library which implements a FixedSize variant of Dictionaries. These can
> be stack allocated and have O(1) indexing performance without boundcheck.
> It implements most parts of the Base.Dict interface. *
> *This package is useful, when you want anonymous composite types. You
> should be a bit careful with generating a lot of FixedSizeDict's, since it
> will compile a unique set of functions for every field of a Dict.*
>
> I'll be using it to speed up various places where I'm currently using a
> dictionary but where the number of keys is set at compile time.
> Also, Shashi <https://github.com/shashi> and I contemplated to implement
> <http://goog_285611601>Extensible Records
> <http://elm-lang.org/docs/records>, which seems like a good fit to
> represent all kind of graphics/geometry types.
> FixedSizeDictionaries could be an integral part of this!
>
> Best,
> Simon
>
> PS:
> I do feel like it's time for a package announcement list...
>