May 20, 2019
On Monday, 20 May 2019 at 18:12:08 UTC, jmh530 wrote:

> If you change the alias to
> alias Num(T) = T;
> and the second is statement to
> is(T : Num!U, U)
> then it becomes equivalent to what I had done above. This fails for the same reason as discussed above.

But with the above reasoning we want this to fail (that is, evaluate is(T == int) as true and go there) because aliases and template aliases are indistinguishable from
the type they alias.
May 20, 2019
On Monday, 20 May 2019 at 18:20:06 UTC, Stefanos Baziotis wrote:
> [snip]
>
> But with the above reasoning we want this to fail (that is, evaluate is(T == int) as true and go there) because aliases and template aliases are indistinguishable from
> the type they alias.

Sorry, it would be true for Num!int, but false for Num!float or something else.
May 20, 2019
On Monday, 20 May 2019 at 19:05:06 UTC, jmh530 wrote:
> On Monday, 20 May 2019 at 18:20:06 UTC, Stefanos Baziotis wrote:
>> [snip]
>>
>> But with the above reasoning we want this to fail (that is, evaluate is(T == int) as true and go there) because aliases and template aliases are indistinguishable from
>> the type they alias.
>
> Sorry, it would be true for Num!int, but false for Num!float or something else.

It makes more sense if I said it should evaluate is(T==int) in the first static if for Num!int and then go to the second static if and evaluate is(T==float) for Num!float.

That's just because of the way you have the static ifs set up.
May 20, 2019
On Monday, 20 May 2019 at 19:07:49 UTC, jmh530 wrote:
> On Monday, 20 May 2019 at 19:05:06 UTC, jmh530 wrote:
>> On Monday, 20 May 2019 at 18:20:06 UTC, Stefanos Baziotis wrote:
>>> [snip]
>>>
>>> But with the above reasoning we want this to fail (that is, evaluate is(T == int) as true and go there) because aliases and template aliases are indistinguishable from
>>> the type they alias.
>>
>> Sorry, it would be true for Num!int, but false for Num!float or something else.
>
> It makes more sense if I said it should evaluate is(T==int) in the first static if for Num!int and then go to the second static if and evaluate is(T==float) for Num!float.
>
> That's just because of the way you have the static ifs set up.

If the second static if is `if(is(T == float))` and we passed float or Num!float,
yes it should go there. If it is as what we said earlier, `is(T : Num!U, U)` it should not evaluate it to true with the reasoning I said above. That is, it doesn't distinguish an int from a Num!int or a float from a Num!float. It goes back to the assumption that aliases and template aliases are indistinguishable from the type they alias.

Again, that is what I _assume_ that is the general direction. The DIP is a step towards that (basically, the root of the problem that the DIP solves is that
the compiler sees the alias and the actual type as 2 different types). Also, that is
what _I_ would think as the better alternative of the 2. That is not to say
that it is the correct / best one.

Certainly, it's what the compiler source seems to move towards. During the semantic analysis, the type of a Num!int variable, becomes an int. I surely don't
have a lot of experience with the compiler internals, but as far as I know, there's
no clear / easy way to know whether it came from an alias or an int.
May 20, 2019
On Monday, 20 May 2019 at 19:25:37 UTC, Stefanos Baziotis wrote:
> [snip]

Sorry, I was getting confused. I was thinking the Num was from a struct, rather than from an alias. Yes, you're right.
May 20, 2019
On Monday, 20 May 2019 at 19:44:57 UTC, jmh530 wrote:
> On Monday, 20 May 2019 at 19:25:37 UTC, Stefanos Baziotis wrote:
>> [snip]
>
> Sorry, I was getting confused. I was thinking the Num was from a struct, rather than from an alias. Yes, you're right.

It's ok, thank you for the feedback!
1 2
Next ›   Last »