What are peoples thoughts on having an inferred type for "cast"? Good/Bad idea? If good, how helpful would this be? Would this break existing code somehow? I think this feature would be a nice added convenience.  Not super helpful but nice to have.

Here's the details
-------------------
Typed Cast: cast(T)v
  try to cast v to T
Type Inferred Cast: cast(auto)v
  try to cast v to whatever type is required in the current context

void foo(string s)
{
  // ...
}
void main()
{
    const(char)[] s = "hello";
    foo(cast(string)s); // Current
    foo(cast(auto) s);  // The type of the cast is inferred to be a string
    foo(cast() s);      // Another possible syntax
}

This would help refactoribility.  If a function argument changes it's type, and the caller is using a cast, then the caller's cast type will be updated automatically.  Note that if it changes to an invalid type, the cast will still fail like normal.

On Thu, 18 Dec 2014 22:46:04 +0000
Jonathan Marler via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> What are peoples thoughts on having an inferred type for "cast"? Good/Bad idea? If good, how helpful would this be? Would this break existing code somehow? I think this feature would be a nice added convenience.  Not super helpful but nice to have.
> 
> Here's the details
> -------------------
> Typed Cast: cast(T)v
>    try to cast v to T
> Type Inferred Cast: cast(auto)v
>    try to cast v to whatever type is required in the current
> context
> 
> void foo(string s)
> {
>    // ...
> }
> void main()
> {
>      const(char)[] s = "hello";
>      foo(cast(string)s); // Current
>      foo(cast(auto) s);  // The type of the cast is inferred to be
> a string
>      foo(cast() s);      // Another possible syntax
> }
> 
> This would help refactoribility.  If a function argument changes it's type, and the caller is using a cast, then the caller's cast type will be updated automatically.  Note that if it changes to an invalid type, the cast will still fail like normal.

using casts is a bad practice. and "auto casts" is... i can't even find a word. the only thing this will help is to hide bugs, i believe.

please, don't.

nothing personal, i'm just terrified by the idea.

On Thursday, 18 December 2014 at 23:06:12 UTC, ketmar via Digitalmars-d wrote:
> the only thing this will help is to hide bugs, i believe.

On the contrary, I find explicit casts hide bugs. Suppose you write:

size_t a = cast(int) b;

It will compile and run. It'll mostly work. But the cast to int probably wasn't intended (it was probably written in 32 bit code and not correctly ported to 64 bit).

How often do we also write auto a = cast(T) b;? The difference would be the type is written on the left side instead of the right. Might make an important differnce when calling functions.

I think the auto cast is a win all around.

On Thursday, 18 December 2014 at 22:46:06 UTC, Jonathan Marler wrote:
>     foo(cast() s);      // Another possible syntax

That already has meaning in D: it strips off qualifiers like casting immutable to mutable. So cast(auto) would be better.

On Thu, 18 Dec 2014 23:18:16 +0000
"Adam D. Ruppe via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> On Thursday, 18 December 2014 at 23:06:12 UTC, ketmar via Digitalmars-d wrote:
> > the only thing this will help is to hide bugs, i believe.
> 
> On the contrary, I find explicit casts hide bugs. Suppose you write:
> 
> size_t a = cast(int) b;
> 
> It will compile and run. It'll mostly work. But the cast to int probably wasn't intended (it was probably written in 32 bit code and not correctly ported to 64 bit).
> 
> How often do we also write auto a = cast(T) b;? The difference would be the type is written on the left side instead of the right. Might make an important differnce when calling functions.
> 
> I think the auto cast is a win all around.

explicit cast are immediately decipherable (except of
`cast(typeof(result))` maybe). i.e. `cast(int)` is surely casts to
`int`. but what is `cast(auto)`? to what type it will cast the value?
this makes the language unnecessary puzzling, and will not save from
bugs anyway.

`size_t a = cast(int)b;`? so `b` must be long/ulong, and the author guarantees that b will never be bigger than `int.max`. perfect. in no way `cast(auto)` will save us from the bug here: it will simply hide the author intentions.

On Thu, 18 Dec 2014 23:18:16 +0000
"Adam D. Ruppe via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> On Thursday, 18 December 2014 at 23:06:12 UTC, ketmar via Digitalmars-d wrote:
> > the only thing this will help is to hide bugs, i believe.
> 
> On the contrary, I find explicit casts hide bugs. Suppose you write:
> 
> size_t a = cast(int) b;
> 
> It will compile and run. It'll mostly work. But the cast to int probably wasn't intended (it was probably written in 32 bit code and not correctly ported to 64 bit).
> 
> How often do we also write auto a = cast(T) b;? The difference would be the type is written on the left side instead of the right. Might make an important differnce when calling functions.
> 
> I think the auto cast is a win all around.

p.s. with functions it's even more puzzling: now i have to look at the function signature to deduce the actual type. if such calls are rare, there is no need for "auto casts". if such calls are frequent, write a wrapper function or template!

On 12/18/14 6:18 PM, Adam D. Ruppe wrote:
> On Thursday, 18 December 2014 at 23:06:12 UTC, ketmar via Digitalmars-d
> wrote:
>> the only thing this will help is to hide bugs, i believe.
>
> On the contrary, I find explicit casts hide bugs. Suppose you write:
>
> size_t a = cast(int) b;
>
> It will compile and run. It'll mostly work. But the cast to int probably
> wasn't intended (it was probably written in 32 bit code and not
> correctly ported to 64 bit).
>
> How often do we also write auto a = cast(T) b;? The difference would be
> the type is written on the left side instead of the right. Might make an
> important differnce when calling functions.
>
> I think the auto cast is a win all around.

I have to agree with ketmar. Cast needs fixing, but this is not it. We need more control over what is cast, not less control.

Your example unwittingly shows the issue :) casts are blunt instruments that force the compiler to abandon it's checks. I'm not as concerned about a changing it's type as I am about b. Change the type of b, and the compiler still happily generates possibly disastrous code.

At this point, we can only say "abandon ALL checks." We can't finely tune this. I think we need something more along the lines of C++'s casting directives.

And in answer to your above code snippet, I see no benefit for:

size_t a = cast(auto) b;

over:

auto a = cast(size_t) b;

-Steve

On Thursday, 18 December 2014 at 23:06:12 UTC, ketmar via Digitalmars-d wrote:
> On Thu, 18 Dec 2014 22:46:04 +0000
> Jonathan Marler via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> What are peoples thoughts on having an inferred type for "cast"? Good/Bad idea? If good, how helpful would this be? Would this break existing code somehow? I think this feature would be a nice added convenience.  Not super helpful but nice to have.
>> 
>> Here's the details
>> -------------------
>> Typed Cast: cast(T)v
>>    try to cast v to T
>> Type Inferred Cast: cast(auto)v
>>    try to cast v to whatever type is required in the current context
>> 
>> void foo(string s)
>> {
>>    // ...
>> }
>> void main()
>> {
>>      const(char)[] s = "hello";
>>      foo(cast(string)s); // Current
>>      foo(cast(auto) s);  // The type of the cast is inferred to be a string
>>      foo(cast() s);      // Another possible syntax
>> }
>> 
>> This would help refactoribility.  If a function argument changes it's type, and the caller is using a cast, then the caller's cast type will be updated automatically.  Note that if it changes to an invalid type, the cast will still fail like normal.
>
> using casts is a bad practice. and "auto casts" is... i can't even find
> a word. the only thing this will help is to hide bugs, i believe.
>
> please, don't.
>
> nothing personal, i'm just terrified by the idea.

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?

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.

On Friday, 19 December 2014 at 15:17:04 UTC, Steven Schveighoffer wrote:
> On 12/18/14 6:18 PM, Adam D. Ruppe wrote:
>> On Thursday, 18 December 2014 at 23:06:12 UTC, ketmar via Digitalmars-d
>> wrote:
>>> the only thing this will help is to hide bugs, i believe.
>>
>> On the contrary, I find explicit casts hide bugs. Suppose you write:
>>
>> size_t a = cast(int) b;
>>
>> It will compile and run. It'll mostly work. But the cast to int probably
>> wasn't intended (it was probably written in 32 bit code and not
>> correctly ported to 64 bit).
>>
>> How often do we also write auto a = cast(T) b;? The difference would be
>> the type is written on the left side instead of the right. Might make an
>> important differnce when calling functions.
>>
>> I think the auto cast is a win all around.
>
> I have to agree with ketmar. Cast needs fixing, but this is not it. We need more control over what is cast, not less control.
>
> Your example unwittingly shows the issue :) casts are blunt instruments that force the compiler to abandon it's checks. I'm not as concerned about a changing it's type as I am about b. Change the type of b, and the compiler still happily generates possibly disastrous code.
>
> At this point, we can only say "abandon ALL checks." We can't finely tune this. I think we need something more along the lines of C++'s casting directives.
>
> And in answer to your above code snippet, I see no benefit for:
>
> size_t a = cast(auto) b;
>
> over:
>
> auto a = cast(size_t) b;
>
> -Steve

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.

The way I look at it, cast(auto) is like saying, "hey compiler, I know this value can't be implicitly converted so just pretend like I've given you an explicit cast to whatever type you need".  Note that this cast is still under the constraints of an explicit cast.  You can't cast a struct to an int or whatever. I can't really think of a case where this would be more dangerous than a typed explicit cast but I didn't think too long:)

Jonathan Marler:

> if we allow return value types to be written as "auto" then it makes since to have cast(auto) as well.

I think "cast(auto)" as I understand in your proposal introduces too often undefined situations, because in many cases the compiler can't know what's the type to cast to, and guessing is not acceptable. So I think it's not a good idea.

But sometimes I have code like this:

void main() {
    int x;
    byte y;
    // ...
    y = cast(typeof(y))x;
}


Here I want to cast x to the type of y to allow the assignment to y. This is perhaps an acceptable semantics for "cast(auto)":


void main() {
    int x;
    byte y;
    // ...
    y = cast(auto)x; // OK
}


In that case the inference for the casting type is easy because the type of y is already defined. More examples:


void foo(byte z) {}
void main() {
    int x;
    // ...
    auto y = cast(auto)x; // Error
    byte y = cast(auto)x; // OK, but not very useful
    foo(cast(auto)x);     // OK
}

Bye,
bearophile