Why is SysTime.init invalid?

[Jonathan M Davis]

On Tuesday, April 01, 2014 05:35:28 ed wrote:
> OK, lazy me just read the std.satetime article again. It appears
> the design is for no invalid values and it is currently a known
> limitation due to CTFE.
> 
> ---
> d_time_nan	There is no equivalent. SysTime.init, which has a null
> TimeZone object, would be the closest, but once CTFE advances to
> the point that you can new up class objects with it,
> SysTime.init's timezone will be LocalTime, so don't rely on
> SysTime.init being invalid. std.datetime in general tries to
> avoid having any invalid states for any of its types. It's
> intended that creating such values be impossible.
> ---
> 
> I would still like to know if there is a way around this so I can
> have my struct default init.

You can certainly have a struct with a SysTime member, but there's no way for 
it to use that SysTime without first assigning a valid value to it - at least, 
not without segfaulting when it tries to use the SysTime in any context which 
it would use its timezone member.

If you really want to have the SysTime be useable in the init value of your 
struct, then you can make it so that each of its member functions which use 
the SysTime member check it for validity first (or have a separate bool which 
indicates whether the SysTime has been assigned to or not), in which case, it 
could assign something like SysTime(0) to it, which would be the valid 
equivalent of SysTime.init.

Unfortunately, that does add extra overhead, but there isn't any way around it 
if you want to have the SysTime be used without having the user of the struct 
assign to it first. It's pretty much the same boat that SysTime itself is in. 
I could make it so that it checks the timezone for null every time it's used 
and assign LocalTime to it if it's null, but that adds constant overhead. My 
decision was that it was better to just live with the fact that SysTime.init 
is invalid. It's debatable though, as it's a trade-off.

- Jonathan M Davis