alias not valid with ~

Ignacious via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Jan 18 18:56:08 PST 2017


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.





More information about the Digitalmars-d-learn mailing list