On Friday, March 29, 2013 15:33:35 Steven Schveighoffer wrote:
> On Fri, 29 Mar 2013 15:22:19 -0400, Jonathan M Davis <jmdavisp...@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
