On Thursday, 3 April 2014 at 06:23:40 UTC, Jonathan M Davis wrote:
On Tuesday, April 01, 2014 03:54:07 Jonathan M Davis wrote:
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.
Actually, after thinking about this more after someone opened a
bug on the
fact that SysTime.init.toString() segfaults (since the timezone
is null)
https://d.puremagic.com/issues/show_bug.cgi?id=12507
I think that I have a solution. It's now possible to
default-intialize the
timezonet to UTC so that SysTime.init is equivalent to
SysTime(0, UTC()). It's
not ideal, because it's not SysTime(0, LocalTime()), and
SysTime normally
defaults to LocalTime, but it will never be possible to
default-initialize it
to LocalTime thanks to the fact that it has to call tzset when
it's
initialized.
You can look my comments in the bug for more details. I've
opened a pull
request with those changes, so the next release will probably
have a valid
SysTime.init, even if it's not SysTime(0, LocalTime()) like
would be ideal.
- Jonathan M Davis
I'll gladly switch to a default SysTime in the next release :)
I'm finding std.datetime very easy to use and overall a great
API. Nice work!
Cheers,
ed
