I do not know if I am missing something but consider:

struct Foo {
  int r;
  int i;
  bool get() {
    return true;  // always return true
  }
  alias get this;
}

So I am wondering how it would be possible to construct Foo from a bool? Otherwise how would the compiler be able to figure out in what scenarios reverse conversion is possible and is intended.

Regards
- Puneet

On 2012-28-13 17:12, d coder <dlang.coder@gmail.com> wrote:

> I do not know if I am missing something but consider:
>
> struct Foo {
>   int r;
>   int i;
>   bool get() {
>     return true;  // always return true
>   }
>   alias get this;
> }
>
> So I am wondering how it would be possible to construct Foo from a bool?
> Otherwise how would the compiler be able to figure out in what scenarios
> reverse conversion is possible and is intended.

get is not an lvalue. If you attempt this today:

struct S {
    bool get() @property {
        return true;
    }
    alias get this;
}

S s;
s = false;

you should get a nice compile error. This would of course also apply in
this new situation. Now, this:

struct S {
    bool get() @property {
        return true;
    }
    void get(bool value) @property {
    }
    alias get this;
}

S s;
s = false;

should work. Given this, I believe default-constructing the value, then
applying normal alias this rules, makes the most sense.

-- 
Simen

On Thursday, December 13, 2012 15:25:10 Simen Kjaeraas wrote:
> As discussed deep in the thread "Is there any reason why arithmetic
> operation
> on shorts and bytes return int?"[1], D currently does not support this
> behavior:
> 
> struct bbyte {
>      byte b;
>      alias b this;
> }
> 
> void foo(bbyte b) {}
> 
> void baz() {
>      byte b;
>      foo(b); // Cannot implicitly convert byte to bbyte.
> }
> 
> bbyte baz( ) {
>      byte b;
>      return b; // Cannot implicitly convert byte to bbyte.
> }
> 
> Kenji Hara points out, and I myself thought, that this was a deliberate design choice. Walter's post[2] in the aforementioned thread indicates (but does not make clear-cut) that he also thinks this implicit construction is desirable.
> 
> A previous discussion with Andrei[3] about implicit conversion of nameless tuples to named tuples resulted in a bug report[4], and it is clear that his view also supports some such form of implicit conversion.
> 
> A long time ago, when dinosaurs roamed the earth, walterandrei.pdf[5] suggested that opImplicitCastTo and opImplicitCastFrom take care of this conversion. Is anything like this still on the drawing board? Should alias this do it? How do we deal with cases were one field is alias this'd, and other fields are not?

I don't see any reason not to support it. if you want coversion to only go one way, then alias a function which returns the value being aliased rather than aliasing a variable. If it doesn't support implicit conversions from other types, then it's impossible to have such implicit conversion in D, and I don't see any reason why it should be disallowed like that, not when you've explicitly said that you want to do an alias like that.

- Jonathan M Davis

On 2012-48-15 06:12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> I don't see any reason not to support it. if you want coversion to only go one
> way, then alias a function which returns the value being aliased rather than
> aliasing a variable. If it doesn't support implicit conversions from other
> types, then it's impossible to have such implicit conversion in D, and I don't
> see any reason why it should be disallowed like that, not when you've
> explicitly said that you want to do an alias like that.

There is a need for clarification for implicit construction of types with
multiple fields and alias this, though. What does this do:

struct S {
   int n;
   string s;
   alias s this;
}

S s = "Foo!";


I can see a few solutions:

1) Disallow implicit construction of these types from the aliased type.
    The problem with this solution is default initialization of other
    fields may be exactly what you want. There may also be problems
    where functions are used for alias this.
2) Default construct the wrapper type, then apply alias this.
3) Use some specialized constructor. Will require some annotation or
    other way to mark it as implicit (@implicit?).


Another, likely less common, problem is with classes with alias this:

class A {
   int n;
   alias n this;
}

A a = 4;


Should this allocate a new A?

-- 
Simen