Updated State of the Specialization
Simon Ochsenreither
simon at ochsenreither.de
Sun Dec 21 15:14:03 UTC 2014
> Which is exactly what the Map.get example in the document proposes;
> migrate the API to a better place, while retaining migration
> compatibility with the billions of lines of outstanding code.
On this we agree.
> But it needs some language help to retain compatibility.
That's the thing I'm skeptic about.
> I think this may be the actual point of contention here; it seems
> you're willing to inflict incompatibility on the user base for the
> sake of progress.
Absolutely not! Everything I suggest is intended to be compatible.
I think the point of contention is that the draft proposes a really
complicated way to "disable" inconvenient methods like Map#get for value
types, and I don't believe that
a) it is absolutely necessary to disable those methods and
b) the complexity is worth it to achieve this goal.
If we start doctoring Map#get and List#remove, what does this draft have
in store for java.util.Date and java.util.Calendar?
My earlier suggestion to just keep inconvenient methods around is even
_more_ compatible for people doing the migration, than selectively
disabling such methods.
If you want to steer people away from those methods, add a
@DeprecatedForValueTypes annotation, let the compiler emit a warning and
be done.
> We've not yet settled on whether user-defined value types can define
> their own default value,
How will this work if you have e. g. an Array of value-type T ... will
you go through the whole array and initialize it to the default value
after allocation? Or require extra bits to track which elements have
been initialized already?
> or whether they just get "all fields initialized to their default
> value". The latter is certainly simpler, but either way, there's a
> path to specializing the aconst_null to this (e.g., invoke no-arg
> "constructor".)
So there are 3+ different ways to do it now? Depending on whether you
are in specialized or erased code and whether you have references,
primitives or value types?
More information about the valhalla-dev
mailing list