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 <[email protected]>
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.
