> I think this one falls under the category of "reasonable, but
> currently unimplemented feature."
Upon closer examination, we had been using Thrift version
20080411-exported and the compiler accepted the previous input, but
actually generated the wrong result.
Given the previous thrift definitions, it was accepted, but B ended up
having:
public B() {
this.a = new A();
}
When we assumed it had something like:
public B() {
this.a = Constants.DEFAULT_A;
}
We were lucky in that when we defined DEFAULT_A, we did not change
any of its defaults, as in my example, so it was defined as:
public class Constants {
public static final A DEFAULT_A = new A();
}
Meaning we got the behavior we desired, by mere chance.
It is nice that the compiler is stricter now, in that we're not allowed
to use a feature that does not exist. :-)
Thinking a bit more about it, having const structs as a default value
poses the question: should the const be copied or just referenced? If it
is just reference, mutating the const struct instance would affect any
previously-constructed structs that were using it as a default value.
Which could be a surprising behavior.
I can open a ticket for this feature--any thoughts on whether the
default value being a const struct should result in same reference or
new copy semantics?
Thanks,
Stephen
