I agree it should be a copy. Very nasty bugs will likely creep in otherwise, when someone mutates one field of const-declared object instance (which most languages don't cleanly support making immutable).
In C++, it has to be a copy, since the fields are statically declared without references or pointers. -----Original Message----- From: Bryan Duxbury [mailto:[email protected]] Sent: Monday, August 23, 2010 2:31 PM To: [email protected] Subject: Re: const bug Generally I would be leaning towards the copy approach. On Mon, Aug 23, 2010 at 2:27 PM, Stephen Haberman <[email protected]>wrote: > > > 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 > >
