Correct, and I don’t think they really need to be. Records lost a lot of their power when tuple calls were removed from the BEAM so they are a fraction of even what they used to be.
Why would they disallow completely legal and to the spec JSON however? At worst they should keep the key as a string instead of converting it to an existing atom when that option is requested.
That’s precisely why I think the limitations of requiring an implementation for the protocol should be required, else they are handled like normal tuples. If there is no implementation defined for the record, even if there is a record, it should still fall back to normal tuple handling (which is the opposite of structs, which default to error’ing instead of normal map handling).
Row-destructuring is absolutely a feature, but it’s not one that is always wanted. That is why I can only think of a single language that has row-typed records that doesn’t have nominally-typed records, that being Elm (which is a fairly low level wrapper around javascript’s object’s), and it’s occasionally been a pain there. The vast majority of languages that have row-typed records also have nominally-typed records, because they serve different purposes.
If it was designed to have such an implementation and it did in fact have such an implementation, then how did it fail I’m quite curious? That sounds like a failure in the implementation itself then?
The implementation was not expecting a keyword list as the second element of the tuple. That’s how the false positive happened. We could tell the implementations to carefully guard its types but that would be yet another downside of the proposed approach. And we are not statically typed, so we can’t rule it out upfront.
Ah so it was less that the failing use was a record and more that it’s name happened to be used for a different purpose, that definitely sounds like part of that fluffy bit of dynamic typing. ^.^
Yeah this is what I require for ProtocolEx, the match and guard is supposed to be very exact for what you want and it gets placed ‘into’ the protocol consolidation directly to allow easy fallback matching (along with a lot of optimizations in the way of inlining code or even allowing macro’s directly into the protocol implementations and more, it’s quite a bit faster and very few of these optimizations rely on the matching part, they could be in normal protocol’s as well).
Although I’d like to see records-with-limitations supported in protocols I can see why you don’t. If you ever do get interested in support however I can try to find time to write a PR for it. ^.^
In the mean time ProtocolEx exists and supports it all, in exchange for a compiler hook entry in mix.exs (I still really really wish Mix could automatically detect these with a sorter for them…).
I’m also still very curious why the implementation of MyDecimal is so much faster than Decimal though, I’m still worried I screwed it up somehow if anyone wants to look at it. ^.^;
