Hi there, this ended up being a pretty long post. Thanks for reading through if you do.

problem definition

Using flatbuffers, one of the major pains I've dealt with is the (understandably) limited support for defaults. In many cases, you wish to define data once, documented and instantiated in your schema directly. You do not wish the defaults to be user mutable. And you do not want an accompanying json implementation.

I'd like to suggest const tables and const fields. These would behave like a "static class" and static constexpr variables in c++. I'm sure you've already thought about this, here's my take on it. You miss every... feature you don't request? ;)

Problem example:

table monster1_greetings {
	data:[string]; // = {"hello", "hi"}; can't do this
}
table monster1 {
	greetings:monster1_greetings;
}

In this example, serializing monster1 wastes a lot of memory to some globally defined struct. Furthermore, you must provide some "default data" alongside this schema (json in this case, if you wish to stay data-driven).

You can at least remedy the memory problem however :

table monster1_greetings {
	data:[string]; // = {"hello", "hi"};
}
table monster1 {
	// other things
}
table all_monster1 {
	greetings:monster1_greetings;
	monsters:[monster1];
}

const tables

Users can define const tables. These allow us to hardcode "default" values in a table. Every field of a const table is assignable (including vectors, unions, etc). These behave like a "static class" singleton in c++. Aka, all accessors and variables are static. When referring to a const table from another table, it acts as a c++ static constexpr variable would. Aka, the variable points to a global constant, shared by all tables of the type.

// This table is "pasted" in generated headers, with static accessors but no setters.
// It's data is allways serialized.
const table monster1_greetings {
	data:[string] = {"hello", "hi"}; // This is allowed in const tables.
}
table monster1 {
	greetings:monster1_greetings; // This is a reference/pointer to the global const monster1_greetings table.
}

// When doing the following:
table all_monster1 {
	monsters:[monster1];
}

// The compiler truly creates :
table all_monster1 {
	greetings:monster1_greetings;
	monsters:[monster1];
}

const variables

Once again, sometimes you have data in the schema you do not want to be mutatable (or writeable). const variables would fix this, and hopefully allow more flexible initialization. For example initializing unions, vectors, etc. I imagine the const variables to work as a static constexpr variable does in c++.

enum monster_type {
	big_monster,
	eminem_the_monster,
}

table big_monster {
	const type:monster_type = big_monster;
	const greetings:[string] = {"hi", "hello"}; // allowed since var is const.
}

table eminem_monster {
	const type:monster_type = eminem_the_monster;
	const greetings:[string] = {"I'm friends with the monster", "that's under my bed"};
}

I could go on, but I think that's enough to get a discussion going. I'm guessing there are limitations for forward and backward compatibility I'm unaware of.

Making schemas more powerful (and self-descriptive to some extent) would make for more generalized serializing/de-serializing without requiring reflection.

Cheers & stay safe.