Inferred Type for Explicit Cast

[Jonathan Marler via Digitalmars-d]

On Saturday, 20 December 2014 at 19:00:57 UTC, ketmar via 
Digitalmars-d wrote:
> On Sat, 20 Dec 2014 18:19:21 +0000
> Jonathan Marler via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>
>> > we can't make `cast` less powerful now, but what we surely 
>> > shouldn't do
>> > is making it more poweful.
>> 
>> You're right we can't make it less powerful because it's 
>> necessary.  If you have an idea on how D could get rid of it 
>> we would all love to hear it:)
>
> something like modula's "system" module: if you need `cast`, or
> pointers, or other "low-level" things, you should import 
> "system"
> module. and you HAVE to write `system.cast(...)`. make it 
> cumbersome!
> let `to!XXX` do the work, with all it's checks. making unsafe 
> features
> easier to use is a way to spread their usage, and i see it as a
> "generally bad thing".

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?  If you wanted to 
make these features harder to use why not make the user type the 
word cast in a different language like Japanese?  Or why not take 
cast out all together and force the developer to use assembly or 
another language?  You said you could make the user import an 
unsafe module, why not go a step further and have them type in a 
password, or have them write out a long specific sequence to 
perform the cast:

byte x = cast$%*%@*@(*#&&!(($)$@)@$(@($)@$$*@(@**(!(byte) y;

I don't agree that making things harder to use is a good idea, 
but I do agree that making things more verbose can be a good idea 
to prevent misuse.  It makes sense because in order to use cast 
you should know what it means and if you know what it means you 
should know the verbose syntax to use it.  That concept makes 
sense.  But in my opinion, the "cast" keyword is enough.  It 
provides a way to audit your code by grepping for the "cast" 
keyword, and any programmer that sees the word cast and doesn't 
understand it will likely look up what it means.  I could get on 
board with adding a restriction that you tell the compiler 
somehow that you are going to use casts in your file (like 
importing the "system" module), but when you go to use it, I 
don't think it should be "harder" to use.  cast(auto) may be 
easier to use but it also makes more sense in some cases.  I've 
listed some of the cases in my other posts but the general idea 
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;
}

Now we have a bug that could be incredibly difficult to find and 
will likely not be found through typical unit testing.  It will 
probably result in weird unexpected runtime crashes as the 
invalid cast error propogates through the program until something 
throws an exception.  The error is caused by having to write the 
same thing in 2 different places.  You have to write the type of 
'val' in the declaration and in the cast. This could have been 
avoided if you used cast(typeof(val)), but what if the name of 
val changes?  Then you have the same situation if another 
variable get's renamed to 'val'.  If you use cast(auto) you don't 
need to maintain the type in both places.  It prevents this 
particular bug.

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.  
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.