Inferred Type for Explicit Cast

[Jonathan Marler via Digitalmars-d]

On Saturday, 20 December 2014 at 19:57:54 UTC, ketmar via 
Digitalmars-d wrote:
> On Sat, 20 Dec 2014 19:26:54 +0000
> Jonathan Marler via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>
>> Hmmmm...an interesting concept.  Make unsafe things harder to 
>> do to discourage their use.  I'm not sure if I agree but maybe 
>> you can convince me. Where do you draw the line?
> the thing is that they aren't only harder to use, but they are 
> also
> explicitly marked as "system" things. i.e. things that should 
> be used
> only if you are *really* know what you're doing.
>
> besides, code with `system.cast()` looks suspiciously "burden", 
> which
> also signals that this is not a thing one should mindlessly use
> everywhere.
>
> something like that.
>
>> is it requires less maintenance. Say you have the following:
>> 
>> void myfunc(uint x)
>> {
>>      ubyte val;
>>      //
>>      // ...
>>      //
>>      val = cast(ubyte)x;
>> }
>> 
>> Now let's say that you need change the value of 'val' to 
>> ushort.
>> 
>> void myfunc(uint x)
>> {
>>      ushort val;
>>      //
>>      // ...
>>      //
>>      val = cast(ubyte)x;
>> }
> why do you need `cast` here? isn't `to!ubyte` looks better? and 
> it's
> not only looks better, it will provide you additional overflow 
> checks
> too. so if you'll throw a '1024' in your unittest, the second 
> version
> will fail, signalling that something is going wrong.
>

Ah yes you are right, to!byte would make more sense because you 
check at runtime whether or not x is within the range of a byte.  
This would make the code crash right away instead of having to 
track down the bug but you still wouldn't see the bug until 
runtime, and may only happen in rare cases that only occur in the 
customer environment.  to!(typeof(val)) would also handle 
changing the type when the type of val changes.  It looks awkward 
though.  It would be nice if "to" handled type inference.

val = to(x);
// instead of val = to!(typeof(val)(x);
// or
val = to!auto(x); // Impossible right now since compiler doesn't 
understand "to"

"val = to!auto(x)" could be useful in some cases but this would 
be the same basic concept as cast(auto) except "to" allows for 
more "sanity" checking.  I'd have to think more about cases where 
cast(auto) would be useful but this is starting to take too much 
of my time so I'll leave that to other people if they want to 
take time to do so.  I've invested enough time into this and if 
no one else wants to support it then no big deal.  Like I said, 
this would only be a minor convenience.

>> Now I'm not saying that cast(auto) is good in all cases, I'm 
>> just trying to get you to see the big picture here.  
>> cast(auto) could be useful and could help prevent maintenance 
>> bugs in SOME cases.
> i see that `cast` should NOT be used in that cases at all. and 
> this
> returns us to "`cast` is hack. avoid the hacks!"
>
>> Yes it can be misused, but I don't agree that making it harder 
>> to use is a good way to prevent misusage, but requiring more 
>> verbosity is good.  You may disagree that "cast" is enough 
>> verbosity but I think that's a matter of opinion.
> sure, i'm just talking about what i see as "good", i'm in no 
> way trying
> to tell that my opinion is the best one. sorry if my words are 
> too
> "forcing". i'm a somewhat sarcastic person IRL, and i don't use 
> English
> in my everyday life, so i can sound too hard sometimes, failing 
> to
> properly translate my twisted style of writing. ;-)

I don't mind your style of writing, some people might be offended 
by it but it doesn't bother me.  When discussing technical 
details it takes a lot of effort to be polite and I'd rather you 
spend that effort in making the details more correct rather then 
trying to be "tactful".