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

[Bill Baxter]

On Tue, Jul 14, 2009 at 10:02 AM, 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;
> }
>

That is cool.  But numToString is a strange name for a function that
turns a string into a uint.  :-P

--bb