dsimcha Wrote:
> == Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
> > On Tue, Jul 14, 2009 at 12:42 PM, Andrei
> > Alexandrescu<seewebsiteforem...@erdani.org> wrote:
> > >> - opImplicitCast
> > >
> > > I think alias this should render that unnecesary.
> > 'alias this' might cover a lot of cases, but this is the pretty big
> > one that I can think of: consider a Bigint or the like. You might
> > want to use such a type transparently in place of any other integer
> > type, i.e. as an array index. Something like "a[bi.toSizet()]" looks
> > pretty awful. But 'alias this' couldn't work in this case, because
> > the underlying representation is *not* an integer. It's probably an
> > array or somesuch. opImplicitCast would allow you to transparently
> > use a Bigint in place of a normal int while still letting you
> > represent the data any way you want (and letting you check the
> > validity of the cast at runtime). Basically any type which represents
> > its data as something other than what you want to implicitly cast to
> > would have the same problem.
>
> But you can alias this a function, not just a member. Example:
>
> import std.conv;
>
> struct Foo {
> string num;
>
> uint numToString() {
> return to!uint(num);
> }
>
> alias numToString this;
> }
First of all I remember Walter saying that current limitation of one alias this
per class/struct is temporary, it would be nice to hear a confirmation.
Secondly, what about implicit cast in another way. I want some arbitrary type
to be implicitly casted to my type. You can say that I can implement alias this
for the former, but what if it is a primitive type. Can constructors be used
for this?
struct A
{
this(int) {
....
}
}
// int now can be implicitly casted to A. Just a syntax sugar.
Eldar
