Maxim Zaks

My 5 cents. - removing padding, is generally a good thing, I am a bit concerned with possible crashes. In FlatBuffersSwift padding is optional and I had issues with A5...

Regarding the optional / required table field status mentioned by @maxburke. I think changing current behaviour is a bad idea in regards to backward and forward compatibility. Marking fields as...

> I absolutely agree with this. I would extend this a bit further to add a proper optional scalar fields. Adding bool flags if a scalar is present or not,...

> Switching to required by default does not break future compatibility any more than the current attribute. There are two options how one can design default behaviour: 1. Convenience first....

> This will be a bit anecdotal, but every time I have been introducing FB to new people, optional by default was quite surprising to them. Ok lets go with...

@aardappel > We can allow cycles if someone invents a verifier that can deal with cycles and uses no memory First thing would be to enhance flatc to detect recursive...

> yes, as opt-in with some kind of `allow_cycles` it could work, if there's enough demand for such a thing. We'd need signed offsets in general then though, or generate...

Regarding keys lookups in FlatBuffers and generally maps in FlexBuffers. A friend of mine pointed out that "Eytzinger layout" might be more efficient than sorted keys + binary search, specifically...

@mikkelfj I agree with you regarding complexity, but as someone mentioned here already, there should be a focus. If the primary focus of FlatBuffers is speed, then it makes sense...

One more idea, which could be introduced in a new version of FlatBuffers. # Trusted Buffer ## Motivation: Introduce a possibility to create a hash, based on the stored data...