Rant: Date and Time fall short of simplicity in D

Lars T. Kyllingstad public at kyllingen.net
Sun Mar 31 03:00:53 PDT 2013


On Saturday, 30 March 2013 at 02:46:27 UTC, Steven Schveighoffer 
wrote:
> On Fri, 29 Mar 2013 18:08:28 -0400, Jonathan M Davis 
> <jmdavisProg at gmx.com> wrote:
>
>> std.conv.to is the standard way to convert one type to 
>> another. I see no
>> reason to introduce stuff specific to core.time or 
>> std.datetime to do
>> conversions. It should just hook into the standard stuff for 
>> that. If
>> everything uses std.conv.to for coverting between types, then 
>> you don't have
>> to worry about figuring out how a particular programmer 
>> decided that their API
>> should do it - be it with casts or asOtherType toOtherType or 
>> whatever.
>> std.conv.to is specifically designed so that any type can hook 
>> their own
>> conversions into it, and then you can just always use 
>> std.conv.to for
>> converting types.
>
> But the one doing the work is core.time.  In essence, you have 
> locked away part of the API behind cast, and in order to get it 
> out without using cast, you have to import another module.
>
> opCast is just a function, it could easily be called opTo, or 
> simply to(T)().

Now that we have the UFCS, std.conv.to should simply be 
implemented as:

    T to(F, T)(F from)
    {
        T t;
        from.convert(t);
        return t;
    }

Then, std.conv should provide convert() functions for built-in 
types, e.g.

   void convert(wstring from, ref string to);
   void convert(long from, ref int to);
   etc.

User-defined types could define their own convert method:

   struct MyType
   {
      void convert(ref MyOtherType tgt);
   }

This is both safer and more flexible than using opCast(), since

  1. you avoid the unfortunate association with the cast operator,
  2. convert() can be virtual if desired,
  3. convert() can be called directly to modify the target 
variable in-place.

Lars


More information about the Digitalmars-d mailing list