On Fri, 29 Mar 2013 17:17:58 -0400, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
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.
When I say "cast(Duration)time is ugly and dangerous" you say, "use
std.conv.to instead." Why?
It seems you are using std.conv.to as part of the API of core.time types.
I can't really understand the point of this. There exists a safe and
necessary conversion (since both provide different features) from a
TickDuration to a Duration. Why would that be an obscure part of the
API? Why would the preferable interface be to use a cast? Why does
std.conv.to have to be involved to get something readable that doesn't
contain the red-flag cast operator? Both TickDuration and Duration know
about each other, there is no reason to make this a dangerous operation
(and yes, casts are dangerous and should be avoided).
It looks to me like the only reason a cast was chosen over a
property/method is *so* it will work with std.conv.to. I contend that it
would be better of std.conv.to was not able to convert these types than to
have to use cast on it to get this behavior.
If std.conv.to cannot work on type-defined conversions without opCast,
then it is poorly implemented. There needs to be a better mechanism.
-Steve
