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

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> On Tue, Jul 14, 2009 at 1:02 PM, dsimcha<dsimcha at yahoo.com> 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;
>> }
> 
> Oh, wow!  :)

Double-wow: you can alias to a function that returns a ref.

Andrei