brimdata
int128, int256 (and unsigned variants) not implemented?
❯ super -c '{a:int64(3.4),b:int128(3.14)}'
no such function at line 1, column 17:
{a:int64(3.4),b:int128(3.14)}
~~~~~~~~~~~~
❯ super -c '{a:int64(3.14),b:cast(3.14, <int128>)}'
{a:3,b:error({message:"shaper type argument is not a type",on:error("missing")})}
I don't have a real use case for these (I was implementing a bytes formatter for human readable output), and AFAIK, Go doesn't have native support for integers larger than 64 bytes, but they're still mentioned in the Primitive Types in the docs.
Hi @chrismo! It's true that not 100% of what's in "specs" docs (such as within the Formats section) are yet fully implemented in the SuperDB tools. I can see how this is a subtle distinction since it's not like there's other implementations out there we can point to, so it would be easy to assume that the implementation would move in lock step with the specs (I've been guilty of making this assumption, myself). I'm not sure if it would have helped in this case but I've made a note-to-self to add some text to the docs setting expectations appropriately. At one time I actually had Issue hyperlinks at places throughout the docs to call attention to things that were unimplemented, but it was sometimes a hassle to maintain and it wasn't clear if any users were reading the docs closely enough to notice, especially when it came to things like these data types that have more niche cases. I guess I have at least one data point on that now. 😄
We'll probably look at adding support for these data types in the tools some time after our first GA SuperDB release comes out. In the meantime we'll hold this issue open in case other users also spot it and want to chime in with their use cases that might lead us to boost the priority of that effort. FYI in case you bump into it as well, the "decimal" types also called out in the Formats docs are not yet implemented either (tracked in #1522).
