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

[Eldar Insafutdinov]

Lars T. Kyllingstad Wrote:

> Eldar Insafutdinov wrote:
> > 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
> 
> 
> I don't think it should be this simple. If I do this:
> 
>    class Vector
>    {
>        this (size_t length) { ... }
>    }
> 
> I don't want to be able to write this:
> 
>    Vector v = 3;
> 
> Nor this:
> 
>    size_t length(Vector v) { ... }
>    assert (length(3) == 3);
> 
> I like the idea of being able to specify arbitrary implicit casts, but 
> not the syntax. Rather, there should be an opImplicitCastFrom operator 
> overload or something.
> 
> -Lars

You are right, in that case opImplicitCastFrom would suffice. I suggested constructors solely for the purpose not to introduce new syntax. Though I doubt this will be implemented. Another thing is that it will create an ambiguity with opAssign.