[Issue 12828] Fix SimpleTimeZone.utcOffset so that it has the correct return type

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Sat May 31 13:24:18 PDT 2014


https://issues.dlang.org/show_bug.cgi?id=12828

--- Comment #1 from Jonathan M Davis <jmdavisProg at gmx.com> ---
I fixed the setter for utcOffset some time ago but didn't fix the getter,
because if I did, it would break code (since the return type changed). I've
been holding out for multiple alias thises in the hopes of declaring something
like

@property auto utcOffset() @safe const pure nothrow
{
    static struct Result
    {
        Duration utcOffset;
        int toInt() @safe const pure nothrow
        {
            return cast(int)utcOffset.total!"minutes"();
        }

        alias utcOffset this;
        deprecated("utcOffset is being change to a Duration. " ~
                   "Please use it as one rather than int. " ~
                   "See documentation for details.")
            alias toInt this;
    }

    return Result(_utcOffset);
}

and then change it to Duration later. However, there is still no sign of
multiple alias thises being implemented, and I'm not sure that they ever will
be. Also, given that we have core.time.minutes as well as
core.time.Duration.minutes, depending on how multiple aliases thises was
implemented, something like

    auto foo = stz.utcOffset.hours;

could result in a compilation error, meaning that we still might break code
with that attempt at a deprecation cycle.

So, what I'm now proposing to do is to simply change it. This _is_
unfortunately a breaking change, but it's _very_ easy to fix, and it's likely
that it's relatively rare for anyone to use SimpleTimeZone.utcOffset. Something
like

    auto foo = stz.utcOffset;

would have to be changed to

    auto foo = cast(int)stz.utcOffset.total!"minutes"();

So, we'd be making std.datetime properly consistent (since everywhere else that
we have utcOffset, it's a Duration) and getting rid of the problem of having a
naked integral value for time. I normally wouldn't go for this, as it does
cause breakage (albeit breakage which is very easy to fix), but I don't see any
other way to fix this design flaw at this point, and it _is_ easy to fix.

--


More information about the Digitalmars-d-bugs mailing list