mixin template's alias parameter ... ignored ?

[someone]

On Tuesday, 13 July 2021 at 05:26:56 UTC, Ali Çehreli wrote:

> Cumbersome because one has to make sure existing casts are 
> correct after changing a type.

ACK.

> Harmful because it bypasses the compiler's type checking.

Hmmm ... I'll be reconsidering my cast usage approach then.

> >> For example, if we change the parameter from 'int' to
> 'long', the cast
> >> in the function body is a bug to be chased and fixed:
> >>
> >> // Used to be 'int arg'
> >> void foo(long arg) {
> >>   // ...
> >>   auto a = cast(int)arg;  // BUG?
> >>   // ...
> >> }
> >
> > nope, I'll never do such a downcast
>
> The point was, nobody did a downcast in that code. The original 
> parameter was 'int' so cast(int) was "correct" initially. Then 
> somebody charnged the parameter to "long" and the cast became 
> potentially harmful.

ACK.

> > UNLESS I previously tested with if
> > () {} for proper int range; I use cast a lot, but this is
> mainly because
> > I am used to strongly-typed languages etc etc,
>
> Hm. I am used to strongly-typed languages as well and that's 
> exactly why I *avoid* casts as much as possible. :)
>
> > for example if for
> > whatever reason I have to:
> >
> > ushort a = 250;
> > ubyte b = cast(ubyte) a;
> >
> > I'll do:
> >
> > ushort a = 250;
> > ubyte b = cast(ubyte) 0; /// redundant of course; but we
> don't have
>
> We have a different way of looking at this. :) My first 
> preference would be:
>
>  ubyte b;
>
> This alternative has less typing than your method and is easier 
> to change the code because 'ubyte' appears only in one place. 
> (DRY principle.)
>
>   auto b = ubyte(0);
>
> Another alternative:
>
>   auto b = ubyte.init;

ACK. I'll be revisiting the whole matter. I just re-read your 
http://ddili.org/ders/d.en/cast.html chapter. I did not have a 
clear understanding between the difference of to!(...) and cast() 
for example; and, re-reading integer promotion and arithmetic 
conversions refreshed my knowledge at this point.

> Ali