class Y
{
   int y;
   alias y this;
}

class X
{
   Y[] x;
   alias x this;
}


Yet X ~= 3; fails.

3 should be implicitly convertible to Y and then ~ should assign it.

?

On 19/01/2017 3:08 PM, Ignacious wrote:
>
> class Y
> {
>    int y;
>    alias y this;
> }
>
> class X
> {
>    Y[] x;
>    alias x this;
> }
>
>
> Yet X ~= 3; fails.
>
> 3 should be implicitly convertible to Y and then ~ should assign it.
>
> ?

This should not fail:

X x = new X;
x ~= 3;

This should fail as x is a member of an instance of class X:

X ~= 3;

On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole wrote:
> On 19/01/2017 3:08 PM, Ignacious wrote:
>>
>> class Y
>> {
>>    int y;
>>    alias y this;
>> }
>>
>> class X
>> {
>>    Y[] x;
>>    alias x this;
>> }

> This should not fail:
>
> X x = new X;
> x ~= 3;


Yes, it should fail. 3 is not implicitly convertible to Y under any circumstance. D does not support implicit constructors.

alias this only works if you ALREADY HAVE a Y, then it will implicitly convert Y to int. It will never go the other way around.

On 19/01/2017 3:25 PM, Adam D. Ruppe wrote:
> On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole wrote:
>> On 19/01/2017 3:08 PM, Ignacious wrote:
>>>
>>> class Y
>>> {
>>>    int y;
>>>    alias y this;
>>> }
>>>
>>> class X
>>> {
>>>    Y[] x;
>>>    alias x this;
>>> }
>
>> This should not fail:
>>
>> X x = new X;
>> x ~= 3;
>
>
> Yes, it should fail. 3 is not implicitly convertible to Y under any
> circumstance. D does not support implicit constructors.
>
> alias this only works if you ALREADY HAVE a Y, then it will implicitly
> convert Y to int. It will never go the other way around.

Oh Y, I read it as int, my bad.
Yes should fail.

On Thursday, 19 January 2017 at 02:25:44 UTC, Adam D. Ruppe wrote:
> On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole wrote:
>> On 19/01/2017 3:08 PM, Ignacious wrote:
>>>
>>> class Y
>>> {
>>>    int y;
>>>    alias y this;
>>> }
>>>
>>> class X
>>> {
>>>    Y[] x;
>>>    alias x this;
>>> }
>
>> This should not fail:
>>
>> X x = new X;
>> x ~= 3;
>
>
> Yes, it should fail. 3 is not implicitly convertible to Y under any circumstance. D does not support implicit constructors.
>
> alias this only works if you ALREADY HAVE a Y, then it will implicitly convert Y to int. It will never go the other way around.

Huh?

But this is alias this, the whole point of alias this is to treat the type as as the alias?

You are saying it basically only works one way, seems to make alias this quite useless(50% at least). Is there any real reason why this doesn't work?

X x;
Y y;
y = 3;

x ~= y; works fine
x ~= 3; fails.

Yet, logically, 3 is convertible to Y(3rd line above) and Y is appendable to X.

Seems to me that D simply hasn't added the logic to handle the case for implicit construction for alias this, why not add it?

On 19/01/2017 3:35 PM, Ignacious wrote:
> On Thursday, 19 January 2017 at 02:25:44 UTC, Adam D. Ruppe wrote:
>> On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole wrote:
>>> On 19/01/2017 3:08 PM, Ignacious wrote:
>>>>
>>>> class Y
>>>> {
>>>>    int y;
>>>>    alias y this;
>>>> }
>>>>
>>>> class X
>>>> {
>>>>    Y[] x;
>>>>    alias x this;
>>>> }
>>
>>> This should not fail:
>>>
>>> X x = new X;
>>> x ~= 3;
>>
>>
>> Yes, it should fail. 3 is not implicitly convertible to Y under any
>> circumstance. D does not support implicit constructors.
>>
>> alias this only works if you ALREADY HAVE a Y, then it will implicitly
>> convert Y to int. It will never go the other way around.
>
> Huh?
>
> But this is alias this, the whole point of alias this is to treat the
> type as as the alias?
>
> You are saying it basically only works one way, seems to make alias this
> quite useless(50% at least). Is there any real reason why this doesn't
> work?
>
> X x;
> Y y;
> y = 3;
>
> x ~= y; works fine
> x ~= 3; fails.
>
> Yet, logically, 3 is convertible to Y(3rd line above) and Y is
> appendable to X.
>
> Seems to me that D simply hasn't added the logic to handle the case for
> implicit construction for alias this, why not add it?

It is not implicitly convertible in any form.
An integer is just a value, probably stored in a register or directly encoded into an instruction.

A class instance is always allocated into memory, in pretty much all cases the heap (stack is explicit in D). So what you're suggesting would require an allocation + calling of a constructor to make it equal.

Now, lets say Y was a struct, then yeah it can work. Because a struct is nothing more than a set of values that go together. Which are commonly allocated on the stack and for smaller ones, be passed around by only registers.

On Thursday, 19 January 2017 at 02:51:03 UTC, rikki cattermole wrote:
> On 19/01/2017 3:35 PM, Ignacious wrote:
>> On Thursday, 19 January 2017 at 02:25:44 UTC, Adam D. Ruppe wrote:
>>> On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole wrote:
>>>> On 19/01/2017 3:08 PM, Ignacious wrote:
>>>>>
>>>>> class Y
>>>>> {
>>>>>    int y;
>>>>>    alias y this;
>>>>> }
>>>>>
>>>>> class X
>>>>> {
>>>>>    Y[] x;
>>>>>    alias x this;
>>>>> }
>>>
>>>> This should not fail:
>>>>
>>>> X x = new X;
>>>> x ~= 3;
>>>
>>>
>>> Yes, it should fail. 3 is not implicitly convertible to Y under any
>>> circumstance. D does not support implicit constructors.
>>>
>>> alias this only works if you ALREADY HAVE a Y, then it will implicitly
>>> convert Y to int. It will never go the other way around.
>>
>> Huh?
>>
>> But this is alias this, the whole point of alias this is to treat the
>> type as as the alias?
>>
>> You are saying it basically only works one way, seems to make alias this
>> quite useless(50% at least). Is there any real reason why this doesn't
>> work?
>>
>> X x;
>> Y y;
>> y = 3;
>>
>> x ~= y; works fine
>> x ~= 3; fails.
>>
>> Yet, logically, 3 is convertible to Y(3rd line above) and Y is
>> appendable to X.
>>
>> Seems to me that D simply hasn't added the logic to handle the case for
>> implicit construction for alias this, why not add it?
>
> It is not implicitly convertible in any form.
> An integer is just a value, probably stored in a register or directly encoded into an instruction.
>

so? An integer is just a type. Where it is stored or how is irrelevant.


> A class instance is always allocated into memory, in pretty much all cases the heap (stack is explicit in D). So what you're suggesting would require an allocation + calling of a constructor to make it equal.
>

So.

> Now, lets say Y was a struct, then yeah it can work. Because a struct is nothing more than a set of values that go together. Which are commonly allocated on the stack and for smaller ones, be passed around by only registers.

So. If it worked for a struct as you suggest it should for for any type.

What you are suggesting is that the compiler(or maybe the compiler programmer) is not able to create a rewrite rule. It obviously can. So your reasons are flawed.

The reason question you should ask yourself is is there any reason not to do it, instead of trying to find reasons it can't be done(sounds more like you are grasping at straws/guessing).

You should realize any time one can program something explicit the compiler can be made to do it implicit. The question is the consequences of such actions. In this case, regardless if we use 3 and convert explicitly or not ~ requires an allocation, so allocations alone are not enough to prevent it.

On Thursday, 19 January 2017 at 02:51:03 UTC, rikki cattermole wrote:
> Now, lets say Y was a struct, then yeah it can work.

In theory, it can work with either (the compiler could just insert the function call to alloc+construct), but it won't in D since we don't have implicit construction.

On Thursday, 19 January 2017 at 02:35:08 UTC, Ignacious wrote:
> But this is alias this, the whole point of alias this is to treat the type as as the alias?

No, alias this is for subtyping. Similar to a child class, a subtype can be used as its parent type, but must be constructed.

class A {}
class B : A {}

A a = new B(); // legal, B will convert to A
B a = new A(); // illegal, A is not B

alias this is the same concept, just outside of class inheritance.

https://en.wikipedia.org/wiki/Subtyping

> Yet, logically, 3 is convertible to Y(3rd line above) and Y is appendable to X.

Wrong. Implicit construction and implicit conversion are different concepts in theory and in practice in every language I know. You often want them separately as construction may need additional state, may just not be logical, and may have a different runtime cost than substitution.

D does not support implicit construction under any circumstance except the typesafe variadic syntax in function calls that take a single class.

(I'd like to add it, but Walter doesn't agree..)