Default value for date/time

Gil Tene gil at
Wed May 9 00:53:09 UTC 2018

Perhaps “works like a double” is a better analogy? Doubles have NaNs. Dates can have NaDs.

Sent from Gil's iPhone

> On May 8, 2018, at 5:48 PM, John Rose <john.r.rose at> wrote:
>> On May 8, 2018, at 5:37 PM, Stephen Colebourne <scolebourne at> wrote:
>> On 9 May 2018 at 01:13, John Rose <john.r.rose at> wrote:
>>>> I worry that while the key principle has got the project a long way,
>>>> it is too hard line when it comes to some potential value types -
>>>> Currency or Money being other examples where a default is silly, but
>>>> they are otherwise fully value-like.
>>> Any value type measuring a scaled amount is going to have a
>>> zero right?  That's the default, probably.  It's affine amounts
>>> like times that don't have a good default.
>> Whats the default Currency? USD is a not an acceptable answer. Money
>> is the same as it can't exist without a currency.
>> What about a Distance object? Is it measured in Miles or Kilometers by default?
> Thanks, I get it now.
>>> class ObserveTheDefault {
>>>  LocalDateValue x;
>>>  LocalDateValue[] a = new LocalDateValue[1];
>>>  void test() {
>>>    System.out.println(x);
>>>    assert(LocalDateValue.default.equals(x));
>>>    System.out.println(a[0]);
>>>    assert(LocalDateValue.default.equals(a[0]));
>>>  }
>>>  public static void main(String… av) { new ObserveTheDefault().test(); }
>>> }
>> My suggestion was that code does not compile as `LocalDateValue x`
>> wasn't assigned in the constructor (not "works like an int", but then
>> its not like an int). Anything else risks allowing a "null-like"
>> LocalDate to escape and head off causing havoc to real code - just
>> like null does...
>> Anyway, I'm not expecting firm/final answers right now - value types
>> has too far to go. Consider my points to be concerns that might be
>> worth considering.
> We'll certainly come back around to this when we've booted up
> the pure "works like an int".  You are asking for a certain kind of
> mashup between objects and primitives, which is understandable,
> but we won't be providing every conceivable point on the spectrum
> between objects and primitives (too hard).  That's why I keep talking
> about trade-offs.  OTOH, maybe what you are asking for is such
> a sweet spot that we'll end up having to do it.  Can't tell right now,
> but… don't hold your breath.  "works like an int" is difficult all by
> itself.
> — John

More information about the valhalla-dev mailing list