Eldar Insafutdinov wrote:
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


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

Reply via email to