Type cast is (not) redundant

I'm pretty sure I've seen this, too.

"Stefan Lieser" <slieser@t-online.de> wrote in message
news:dj09lt$g2p$1@is.intellij.net...

Hi,

>

the following code shows a cast that is necessary to get the needed
result. ReSharper states this cast redundant, but if you remove it, the
test will fail.

>
>

Sincerely,
Stefan Lieser

>
>

using NUnit.Framework;

>

namespace Casting
{
public class CastNeeded
{
public static double Round(double value) {
return (long)(value * 10.0 + 0.5) / 10.0;
}
}

>

public class TestIt {

public void CastIsNeeded() {
Assert.AreEqual(1.4, CastNeeded.Round(1.44));
Assert.AreEqual(1.5, CastNeeded.Round(1.45));
}
}
}

>

The cast is redundant according to C# syntax (You can cast double to double
or float to double). The problem is that in the case it has additional
SEMANTIC meaning.
To emphasize the meaning You'd better write

long x = (long)(value * 10.0 + 0.5) / 10.0;
return x;

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hello Sergey,

"Sergey V. Coox (JetBrains)" <qx@intellij.com> schrieb im Newsbeitrag
news:dj2d3g$a68$1@is.intellij.net...

The cast is redundant according to C# syntax (You can cast double to
double or float to double). The problem is that in the case it has
additional SEMANTIC meaning.

Correct. But ReSharper should NEVER change the semantic of my code.

To emphasize the meaning You'd better write

>

long x = (long)(value * 10.0 + 0.5) / 10.0;
return x;

No, that's also wrong. The cast is needed to truncate the term (value * 10.0
+ 0.5). After the cast to long (which truncates) the term is divided by 10.0
and returned as double.

You could write the following:

long x = (long)(value * 10.0 + 0.5);
return x / 10.0;

But why shall I introduce the temporary variable x? I think ReSharper should
identify the semantic meaning of the cast by looking at the terms that are
effected by the cast.


Sincerely,
Stefan Lieser

Correct. But ReSharper should NEVER change the semantic of my code.

How to distinguish the intentionally added cast and the typo?
The only idea I have is to add a new type of warning - casts with semantics
meaning and to treat the cases like casts between number types in some
special way.

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

"Sergey V. Coox (JetBrains)" <qx@intellij.com> schrieb im Newsbeitrag
news:dj2ea2$gr4$1@is.intellij.net...
>> Correct. But ReSharper should NEVER change the semantic of my code.

How to distinguish the intentionally added cast and the typo?

You can't, so you cannot blame the cast "redundant".

But if the cast does not alter the semantic, you can blame it. And that's
what I expect from ReSharper ;)


Sincerely,
Stefan Lieser

This is no cast but an implicit conversion.

A true cast is always up/down the object hirarchy, this one is sideways through the hirarchy by using (hidden) conversion functions. That should be detectable. Any cast using a conversion possibly has some semantic meaning and should not be flagged as redundant.

It might be nice to have a warning about casts (and operators) that cause these kinds of semanic changes.

For example:
10/3 yields 3 while 10d/3d yields 3 1/3

A lot of developers make these mistakes, caused by (the lack of/the automatic use of) implicit conversions

Fixed in build 208

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Stefan Lieser" <slieser@t-online.de> wrote in message
news:dj09lt$g2p$1@is.intellij.net...

Hi,

>

the following code shows a cast that is necessary to get the needed
result. ReSharper states this cast redundant, but if you remove it, the
test will fail.

>
>

Sincerely,
Stefan Lieser

>
>

using NUnit.Framework;

>

namespace Casting
{
public class CastNeeded
{
public static double Round(double value) {
return (long)(value * 10.0 + 0.5) / 10.0;
}
}

>

public class TestIt {

public void CastIsNeeded() {
Assert.AreEqual(1.4, CastNeeded.Round(1.44));
Assert.AreEqual(1.5, CastNeeded.Round(1.45));
}
}
}

>

"Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> schrieb im
Newsbeitrag news:djkoen$3t1$1@is.intellij.net...

Fixed in build 208

Great!

Btw. do you have any idea how long we have to wait for 208 ?


Sincerely,
Stefan Lieser