Inferred Type for Explicit Cast

[Jonathan Marler via Digitalmars-d]

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?