4 ms·
Is this only relevant for string based btree implementations? Or is this more relevant for custom rolled btrees for a concrete set of types
by czipperz 3y ago
Is this only relevant for string based btree implementations? Or is this more relevant for custom rolled btrees for a concrete set of types
- o11c 3y agoThis kind of thing makes me really wish we lived in a world where languages/libraries had first-class support for containers. C++ at least tries but falls so far short.
- DylanSp 3y agoWhat would that first-class support look like? Having more container types as language built-in?
- Tyr42 3y agoA functor typeclass?
- o11c 3y agoIt's not that the types need to be built-in, but that the compiler needs to know that a type supports an interface, and the library needs to take advantage appropriately. For this particular case, key-based containers need to know if their key is a homogeneous sequence. But that's actually slightly too restrictive - in particular, a fixed-size prefix of a different type isn't actually any harder to optimize for, assuming the introspection API is good enough. But for other things ... even "just give me the list of fields that this class has" involves containers. Implementing compare/hash efficiently (with short-circuiting!) requires peeking inside the heterogeneous tuple. Writing a partial JSON-like object literal? That's a container, and one with very common uses. Making a copy of an object with certain fields replaced? A container. Functions that take keyword arguments? A container which you would really like to propagate sanely. But most compilers that deal with such things don't actually support the usual container APIs, often even lacking simple concatenation (speaking of which - what about compile-time duplicate key detection?).