Developing a plan for D2.0: Getting everything on the table

[Eldar Insafutdinov]

dsimcha Wrote:

> == Quote from Jarrett Billingsley (jarrett.billingsley at gmail.com)'s article
> > On Tue, Jul 14, 2009 at 12:42 PM, Andrei
> > Alexandrescu<SeeWebsiteForEmail at 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