> On May 15, 2018, at 4:53 PM, John Rose <[email protected]> wrote: > > If we can implement EVBCs easily as a one-off from full value type, > in the context of L-world, should we try it? People responsible for > user model (hi Brian!) might say "yuck, we are admitting design > failure by giving a consolation prize to the VBCs, instead of the > real VTs promised". Maybe EVBCs are the best engineering > compromise, or maybe we just cut EVBCs off the feature list > and say "VT or VT not", at which point people who wrote VBCs > will have sad decisions to make, and Dan will tell them not to > migrate at all.
Yeah, I'm pretty down on the benefit of these half-value classes. We'd be better off deprecating the old API classes and introducing new, "real" value class versions. The great thing about use site expressiveness is that different clients can choose different trade-offs, rather than forcing a single choice on all clients. The one declaration-site strategy I could see being viable is (per Maurizio, above) to allow a value class to assert that its default value should be treated as null, with all associated semantics (ifnull, NPE checks). Then your safe migration path for VBCs is to design a field layout that has an acceptable 'null' encoding—often no sacrifice at all.
