Rant: Date and Time fall short of simplicity in D

[Jonathan M Davis]

On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
> The issue is when you think you are invoking the opCast operator, but you
> inadvertently end up casting using the compiler's type-bypassing version.
> I agree the opCast call is safe, it's that its name coincides with the
> "throw all typechecks away" operator.

I'd have to experiment to see exactly what is and isn't accepted, but in my 
experience, the compiler rarely allows casting to or from structs without 
opCast (the same with classes except for the inheritance tree). So, I really 
don't think that there's much risk of accidentally using a cast on a user-
defined type and have it use the built-in cast operator.

> I don't think to should ignore opCast, or not use it, but there should be
> a way to hook 'to' without using opCast.  And most types should prefer
> that.

I really just don't see a problem here. If opCast is defined, it's perfectly 
safe regardless of what would happen if you tried to cast without opCast being 
defined. It's also the language-defined way to do type conversions. And I really 
don't see any need to use anything else to make std.conv.to work. By using 
opCast, there's a standard way to define type conversion, and there's a 
standard way for it to hook into std.conv.to, which seems way better to me 
than trying to support every which way that a particular programmer wants to 
try and define a conversion function. Clearly, you think that using opCast is a 
problem, but I just don't agree. It's safe; it's standard; and it works.

- Jonathan M Davis