It might do, but it's entirely possible that the Swift team will introduce an alternative evolution mechanic. Importantly, though, with this version of the guarantee you need to call the function readTrivialFrozenType and at this point we're deep into the weeds. The odds that someone passes the correct type to this function, given the need to annotate it @frozen, use only trivial types, and get the padding correct, are basically zero.
1 Like
I'm not as active on the forums as I should be, but you were spot-on up earlier in the thread. BSON uses NIO.ByteBuffer, because MongoKitten uses NIO, and because I didn't want to introduce a new type for managing buffers, I stuck with the type that is most dominant in Server-Side Swift.
That being said, I completely agree with the need of a ByteBuffer type outside of NIO.
The reason for BSON depending on Foundation is extremely similar, most developers use Foundation, whether I agree with it or not. And not supporting Foundation types like Date and Data causes more confusion and problems for the 99% of users. I personally dislike the bulky Foundation we have today as well, and I think most of the legacy it's inherited is not that well suites for a Swift on the Server ecosystem.
Problem is, this is the status quo, and while I could reimplement pieces of Foundation myself to suite my needs (as I have done with IkigaJSON's JSONDecoder), I cannot expect everyone to switch to my Date type to name an obvious example. That, and the fact I'm just one developer maintaining a hell of a lot of libraries, which doesn't make it feasible to add more backlog on my already pressed agenda.
Anyways, that's definitely worth being a topic in and of itself.
5 Likes
to pick off some low-hanging fruit, i found that BSON can compile with just NIOCore (previously it was depending on the NIO product). here is a small patch to narrow the dependency:
3 Likes