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