Historically hasLength!R yielded true for types whereby R.length returns other types convertible to ulong, such as int, ushort, const(size_t), user-defined types using alias this, or notably ulong on 32-bit systems. This behavior has been deprecated. After December 2017, std.range.primitives.hasLength will yield true only if R.length yields the exact type size_t.

std.datetime is now a package containing the following modules:

The std.datetime package publicly imports all of those modules. So, it should be the case that no existing code will break, as everything in std.datetime will still be imported by importing std.datetime. New code can choose to import the modules individually or to import the entire package.

std.datetime.date contains Date, TimeOfDay, DateTime, and the related free functions. It also contains DateTimeException.

std.datetime.interval contains the *Interval and *IntervalRange types as well as the related free functions.

std.datetime.systime contains SysTime and the related free functions.

std.datetime.timezone contains the time zone types.

The std.datetime package contains StopWatch and the benchmarking functions (so, they can only be imported via std.datetime and not via a submodule). As those functions use core.time.TickDuration (which is being replaced by core.time.MonoTime, they are slated for deprecation).

std.datetime.stopwatch has been added. It contains versions of StopWatch and benchmark which have almost the same API as the existing symbols, but they use core.time.MonoTime and core.time.Duration instead of core.time.TickDuration. In the next major release, the old functions in std.datetime.package will be deprecated, so code which uses the old benchmarking functions should be updated to use std.datetime.stopwatch.

However, note that in order to avoid irreconcilable symbol conflicts between the new and old versions, std.datetime.stopwatch will not be publicly imported by std.datetime.package until the old symbols have been removed. So, for the time being, code using std.datetime.stopwatch.StopWatch or std.datetime.stopwatch.benchmark will need to import std.datetime.stopwatch directly. Code which imports both std.datetime and std.datetime.stopwatch will need to either use selective imports or fully qualified symbols to reconcile the symbol conflicts, but no code will be affected by the changes until it's updated to import std.datetime.stopwatch, and when the old symbols are finally removed, the selective imports and fully qualified paths to the new symbols will continue to work and won't break (though at that point, simply importing std.datetime will work, since std.datetime.package will have been updated to publicly import std.datetime.stopwatch). Code that simply imporst std.datetime.stopwatch without importing std.datetime will not have to worry about symbol conflicts.