Inferred Type for Explicit Cast

[Jonathan Marler via Digitalmars-d]

On Saturday, 20 December 2014 at 12:36:50 UTC, ketmar via 
Digitalmars-d wrote:
> On Sat, 20 Dec 2014 08:18:22 +0000
> Jonathan Marler via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>
>> Performing a grep on phobos reveals there are currently almost 
>> 3,000 casts.  I never like to use casts but they are a 
>> necessary evil.  I think anything D can do to help the 
>> programmer get their job done is a win.  The initial "pro" I 
>> saw for this idea was improving refactoribility.  I see this 
>> as a huge win.  You claim it will hide bugs?  Could you give 
>> an example?
> autocasting to the types of function arguments is the immediate 
> weak
> point.

I see this as one of it's strong points.  It provides greater 
refactoribility, and also has the potential for using casts 
inside templates to unnamed variables (like function arguments).

> ..what you doing by this is destroying type checking. ok, we 
> doing
> that from time to time, but you proposing handy sytax for it 
> which will
> not break when function signature changes.

casting is not destroying the type checking.  You can't convert a 
value to any type (an int to a struct), it still has to be 
possible.

struct MyStruct{...}
int x;
MyStruct s;
x = cast(int)s; // doesn't work
x = cast(auto)s; // still doesn't work

>
> there is topic about "kind of programmers" nearby, where we 
> found that
> "majority of programmers don't read books". and they tend to 
> use the
> first tool they see to "make the job done", don't trying to 
> evaluate
> the long-term consequences. i can assure you that you'll see
> `cast(auto)` all over their code, 'cause it's simply, it doesn't
> require even looking at function signature and trying to grasp 
> why it
> accepts the given types, and "ah, it's so refactorable!" (they 
> love
> "refactoring", 'cause they don't like to design their software, 
> plus
> "refactoring" is often the blessed way to do nothing really 
> valuable
> and still got payed).

I'm not sure you'll get too many good programmers who agree with 
you that refactoring is only caused by "lack of design".  I'm not 
sure where to start when trying to list all the reasons someone 
would want to refactor.  New library, better design patter is 
realized, new feature has come in, new person has come in with a 
better solution, new api is introduced somewhere...so many 
reasons.  Programmer's aren't perfect, if we did everything right 
the first time then we never would have had c++ :)  D itself is 
just a refactor.

To address your other concern about seeing "cast(auto)" all over 
someone's code.  I think you might start seeing cast(auto) in 
place of some cast(T), but why would you start seeing cast(auto) 
in other places?  Nobody writes cast when it's unnecessary:

int x;
int y = cast(int)x;

Why would anyone do this?  Don't tell me it's because the 
programmer is too stupid to know what a cast means, you could 
make that same argument for any feature.  Some languages have 
used that argument to remove any number of unsafe features like 
pointer arithmetic, non-garbage collected memory, etc.  The 
purpose of D is not to restrict the programmer so they can't make 
any mistakes, it's purpose is to make programming easier and of 
course safer but not at the expense of removing the ability to do 
the unsafe operations when needed. It is true that 'cast' reduces 
type checking, but it doesn't remove it and it's also necessary.

>
> besides, `cast` is a hack by itself. the good way to deal with 
> hacks is
> to make them less powerful, not more powerful. you are 
> proposing to
> make the hack more powerful. there is nothing bad in it... when 
> the
> language is designed for use by hardcore hackers. but for 
> languages
> with greater audience this is not a good way to go. hacks will
> inevitably be abused. it doesn't matter how many times we write 
> in big
> letters: "PLEASE, DON'T DO THAT!" so hacks must be small and
> fine-grained, not small and powerful.

cast is not a hack, it's a necessary feature that is well 
defined.  It reduces type safety, which may be why you are 
calling it a "hack", but unfortunately it is necessary.  
cast(auto) is a natural extension to a necessary feature that's 
not going to go away. Type safety is not a simple problem.  The 
more type safe you get the more restrictive your language gets, 
which causes more need for casting.  The less type safe your 
language is, the less casting you need but then the more unsafe 
your whole program becomes.  D often chooses to make 90% of code 
safe and provides ways for you to escape the safety of the 
language for the extra 10%.  Cast falls into the category of the 
10%. If you go through some examples I think you'll find that 
cast(auto) used in the cases where it makes sense actually 
produces code that results in less bugs.  But like any tool, of 
course it can be misused, but that's not a reason to not have it.

>
> besides, `cast(auto)` is not decipherable without analyzing the
> expression (and, possibly, function signature). it is not clear 
> what
> result of `cast(auto)` will be. this is bad for hack.
>

Normal auto declarations and using auto as a return type has the 
same problem. But sometimes you don't care what the type is.  If 
you always needed to know what type something is then templates 
wouldn't exist.

> why `cast` is hack? 'cause it turns off most of the compiler 
> type
> checking system. that's why we have `to!XXX` thing, which is 
> not so
> disasterous. and compiler is smart enough to see that `a&0xff` 
> is good
> for ubyte, for example.

Again, it doesn't "turn off" type checking, it makes types 
checking more lenient which is sometimes necessary.

>
> 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:)

>
>> When I requested other people to chime in on this idea I was 
>> more looking for data/examples.  Maybe someone will think of 
>> an example that shows this idea could encourage bad coding 
>> practices?  Maybe it will hide bugs?  My point is, I don't 
>> want to discourage you from providing your opinion, but I  
>> would really like to understand where your opinion comes from. 
>> I hope that wasn't harsh, I've read other posts you've made on 
>> the forums and although I don't agree with everything you say 
>> I would value your assessment. Thanks.
> it comes from my past expirience. sometimes i just *sense* the 
> smell.
> powerful hacks are great troublemakers. making Cassandra 
> prophecies is
> my superpower. ;-)