On Sunday, 21 December 2014 at 03:04:05 UTC, Steven Schveighoffer
wrote:
On 12/20/14 3:36 AM, Jonathan Marler wrote:
Nobody likes to use cast, but for now we are stuck with it.
Creating
alternatives to cast would be a great thing to discuss but
doesn't
really apply to the point at hand, which is, would cast(auto)
be a
useful extension to our current cast operator? I think it
could be. In
my opinion, if we allow return value types to be written as
"auto" then
it makes since to have cast(auto) as well. In both cases the
developer
would need to look somewhere else to find what type "auto"
actually gets
resolved to.
You have to be careful here, when you think about who is in
charge of what.
For an auto return, it is the function author who is deciding
what auto should resolve to. But cast(auto) is letting the
author of the called function dictate. This is a decoupling of
who is responsible for the type vs. who is requesting the cast.
Now, just 'auto' is fine, because you are not subverting the
type system, and unsafe behavior cannot result. But with
something like 'cast', you are potentially playing with fire.
For instance, let's say you have a function which accepts an
int, but the author changes it later to accept a pointer to an
int. You are passing in a size_t, via cast(auto), now the
compiler happily reinterprets the size_t as a pointer, and you
are in dangerous territory.
You can think of it this way. With cast(T), you are saying
"I've examined the possibilities of casting this value to type
T, I know what I'm doing". With cast(auto) you are saying "I'm
OK with this value casting to any other value that cast may
work with. I know what I'm doing." I find that the requirement
of just typing "cast(auto)" does not match the gravity of the
analysis that is required to ensure that is true.
-Steve
That is a case I hadn't initially thought of. I definitely don't
like that.
As for the typed cast, what about when the function argument is
changed from a byte to a short? If the initial caller was using
cast(byte) and doesn't change to cast(short), then you are also
creating a bug. I feel like you're going to get different bugs
either way. Both the typed and auto-typed cast seem to be just
as dangerous. That's not really an argument to have auto-cast,
I'm just making an observation.
I noticed your other comment about wanting a double-typed cast.
I could see that being useful especially if we did something like
this:
When a cast is performed, the source and target type must match
the expected types EXACTLY.
int y;
ushort x = cast(byte, int)y; // cast from int to byte
This should definitely produce an error. This code could exist
if x was initially a byte and was later changed to a ushort. I
think this feature would make casts alot safer because any time a
type was changed you would get an error saying you need to go
update all your casts. What do you think?
