Rant: Date and Time fall short of simplicity in D

[Jonathan M Davis]

On Friday, March 29, 2013 15:33:35 Steven Schveighoffer wrote:
> On Fri, 29 Mar 2013 15:22:19 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
> >> 3. I HATE "safe" cast conversions. If you want to make a conversion,
> >> use
> >> a method/property. I don't even know why D allows overloading casting.
> >> Casts are way too blunt for this.
> > 
> > It's how you define coversions to work with std.conv.to, so you could do
> > to!DateTime(sysTime), which is shorter and avoids the explicit cast in
> > your
> > code (though the cast still occurs within std.conv.to).
> 
> This seems like a horrible round-about way of creating a method:
> 
> 1. Define opCast!OtherType
> 2. import std.conv
> 3. instead of using obj.toOtherType, use to!OtherType(obj)
> 
> Do we really need to go through this mess? I understand the point is for
> 'to' to be usable in generic code, but can't to be made to call the
> correct method instead of using cast? I don't really like to using cast
> in this case anyway.
> 
> What about something like (omitting necessary constraints in the interest
> of brevity):
> 
> T to(T, U)(U u)
> {
> return mixin!("u.to" ~ T.stringof);
> }
> 
> Or at least just alias the opCast to the method.

It used to be that std.conv.to used to on the type, but it was decided to get 
rid of that in favor of using opCast. I don't remember all of the reasons for 
it though.

But std.conv.to is the standard way to convert things, and I don't see how 
changing how std.conv.to determines how to do the conversion would help us 
any. Whether there was a to function on the type or opCast really makes no 
difference if you're using std.conv.to, and if you're not, then the way that 
the language provides to covert types - casting - works.

Unless you're arguing for using something other than std.conv.to to convert 
types, I really don't see the problem, and arguably, because std.conv.to is 
really the standard way to convert stuff, it's what should be used. So, I could 
see a definite argument for using std.conv.to in code rather than opCast, but I 
don't see much point in avoiding defining opCast on types, especially if code 
is then generally using std.conv.to rather than casting directly.

- Jonathan M Davis