Wouter van Oortmerssen

@dbaileychess has all the keys for doing releases, though if someone external would want to be in charge of that, that could work too. That said, we have so far...

@krojew 1) is not a problem. In the most basic case you make every scalar load go thru `memcpy` which gets optimized by every compiler (tested with clang, gcc and...

@mikkelfj not sure why you refer to some of these as "slow": like I said, these are all intended to be codegen-ed (or become a template/macro arg) so will all...

@AustinSchuh forward building would be a big format change, since now children typically come before parents, and unsigned child offsets would be flipped to always point downwards in memory instead....

@maxburke the varints would be very much optional, as they are definitely slower to read. They would be a type, so you'd explicitly write either `int` (as right now) or...

@AustinSchuh > The offset for the scalar fields in the vtable is 0 if they aren't populated Yes, and that means that the value is equal to the default, not...

@rw > Maybe a varint? That would make the distinction dynamic, and costly. Besides, we need to index into this table, which makes varints useless unless all the same size....

@mzaks Unaligned accesses will crash on ARM if the C/C++ (or Swift) code was generated assuming alignment, since unlike x86 they are different instructions. But it is pretty easy to...

@mustiikhalil if you wanted to remove vtables and make everything required, then your ideal format already exists: it's called Cap'n Proto! ;)

I recommend we do not go to far into the "required vs optional" default discussion, because in the end this is an API/schema feature, not a binary format feature, assuming...