gbc shouldn't allow struct fields to have default of nothing

[chadwalters]

gbc shouldn't allow struct fields to have default of nothing. The following schema definition should fail:

struct A
{
    0: int32 x;
}

struct B
{
    0: A a = nothing;
}

[chwarr]

Related: #72, #73, #128.

[lalo]

So basically struct fields can never have a default value?

This is the only valid syntax?

struct A
{
    0: int32 x;
}

struct B
{
    0: A a;
}

[chadwalters]

Correct; struct fields can't have default values.

[chwarr]

Bond version 4.3.0 is now live on NuGet.org. These changes are included in that version.

[clarkrd]

A default value of nothing allowed an optional struct field omitted by the sender to deserialize to nothing. Doesn't this mean that an optional struct field omitted by the sender will now automatically deserialize into an instance with all its default field value set? That seems like a major and breaking change. Is there a way to specify that an optional struct field should simply deserialize to nothing if omitted? This was the previous compiler behavior and it had a very clear and useful semantic.

Does this mean that we need to make all such struct fields nullable in the schema in order to avoid serializing / deserializing default values for the struct? This requires major changes to existing schemas to get back the previous behavior support by allowing nothing as a default value for a struct.

[chwarr]

Thanks for bringing this up, @clarkrd, and sorry about the churn.

Doesn't this mean that an optional struct field omitted by the sender will now automatically deserialize into an instance with all its default field value set?

Yes, that is what will happen (and what was supposed to happen before: read on).

That seems like a major and breaking change. ... This was the previous compiler behavior and it had a very clear and useful semantic.

The compiler was never supposed to allow struct fields to be = nothing. That it allowed it was a bug.

Why was it a bug? Because of the history of Bond before it went open source... There is a Microsoft-internal, older version of Bond. The internal version of Bond has been around for many, many years. The older compiler is a completely different code base from the current one. It never allowed struct fields to be = nothing. So, from this perspective, the = nothing behavior of gbc is a regression.

At the moment, the various teams at Microsoft are migrating from the old, internal version to gbc. During this transition, we need to make it possible to use the same .bond file with both compilers.

However, there are interesting possibilities for struct fields with a default value of nothing. I've opened #226, "Consider adding support for struct fields to have a default value of nothing" to explore these possibilities.

Is there a way to specify that an optional struct field should simply deserialize to nothing if omitted?

If the semantic of the field is that sometimes the producer wants to include it, but not always, then nullable<> is how you should model that. It indicates the explicit ability to "not have a value". Let's say that = nothing support were added/restored. You still wouldn't be able to assign null and be guaranteed to serialize the value. Serialization to Simple Binary, for example, would fail, as Simple Binary cannot omit any fields and the value of null for an = nothing field doesn't have a serializable representation, where as null does have a serializable representation for a nullable<> field.

Does this mean that we need to make all such struct fields nullable in the schema in order to avoid serializing / deserializing default values for the struct?

That is a way to do it. Another way is to look at a field in the inner struct and check whether it has it default value--assuming the default value is not meaningfully used, which is sometimes the case.

I understand that this change might need some schema adjustments. If anyone needs help, feel free to open a new issue with details about the schemas in question, and we'll see what we can come up with that will be minimally disruptive. And, if we can't, we'll need to figure out a different way forward.