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@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. ;-)
