C# explicit operators aren't that explicit :(
-
Usually, I'm a big fan of C#. Today it's irritating me a little bit :( I have a case where I would like to perform an implicit conversion for my class when a
doubleis assigned to it, but not do one for anint. Yeah, I know, its an odd requirement! Suffice to say, it would make my life a little simpler, if I could get away with it. Initially, it seems like C# should allow me to do it. If I mark the operator forintasexplicit, I get the error I want. Regrettably, when I then add the operator fordouble, which isimplicit, the error goes away. I do understand why, and understand that C# "is-what-it-is", which is usually a good thing. However, today, I truly wish theexplicitoperator took precedence over theimplicitoperator! Oh well, there are plenty of work-arounds, but they end up being far less elegant in this particular code base. For your consideration, here's a code snippet that demonstrates the behavior. Comment out the line with theimplicitoperator and you get the error I want. Without it, the integer gets implicitly converted to a double and uses that operator, so no error.namespace ExplicitOperator
{
public class Program
{
public static void Main(string[] args)
{
int value = 5;
Test test = value;
}public class Test { public Test(double value) => Value = value; public Test(int value) => Value = value; public double Value { get; } public static explicit operator Test(int value) => new Test(value); public static implicit operator Test(double value) => new Test(value); }}
} -
Usually, I'm a big fan of C#. Today it's irritating me a little bit :( I have a case where I would like to perform an implicit conversion for my class when a
doubleis assigned to it, but not do one for anint. Yeah, I know, its an odd requirement! Suffice to say, it would make my life a little simpler, if I could get away with it. Initially, it seems like C# should allow me to do it. If I mark the operator forintasexplicit, I get the error I want. Regrettably, when I then add the operator fordouble, which isimplicit, the error goes away. I do understand why, and understand that C# "is-what-it-is", which is usually a good thing. However, today, I truly wish theexplicitoperator took precedence over theimplicitoperator! Oh well, there are plenty of work-arounds, but they end up being far less elegant in this particular code base. For your consideration, here's a code snippet that demonstrates the behavior. Comment out the line with theimplicitoperator and you get the error I want. Without it, the integer gets implicitly converted to a double and uses that operator, so no error.namespace ExplicitOperator
{
public class Program
{
public static void Main(string[] args)
{
int value = 5;
Test test = value;
}public class Test { public Test(double value) => Value = value; public Test(int value) => Value = value; public double Value { get; } public static explicit operator Test(int value) => new Test(value); public static implicit operator Test(double value) => new Test(value); }}
}I think this would be an excellent post for the C# language forum !
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
Usually, I'm a big fan of C#. Today it's irritating me a little bit :( I have a case where I would like to perform an implicit conversion for my class when a
doubleis assigned to it, but not do one for anint. Yeah, I know, its an odd requirement! Suffice to say, it would make my life a little simpler, if I could get away with it. Initially, it seems like C# should allow me to do it. If I mark the operator forintasexplicit, I get the error I want. Regrettably, when I then add the operator fordouble, which isimplicit, the error goes away. I do understand why, and understand that C# "is-what-it-is", which is usually a good thing. However, today, I truly wish theexplicitoperator took precedence over theimplicitoperator! Oh well, there are plenty of work-arounds, but they end up being far less elegant in this particular code base. For your consideration, here's a code snippet that demonstrates the behavior. Comment out the line with theimplicitoperator and you get the error I want. Without it, the integer gets implicitly converted to a double and uses that operator, so no error.namespace ExplicitOperator
{
public class Program
{
public static void Main(string[] args)
{
int value = 5;
Test test = value;
}public class Test { public Test(double value) => Value = value; public Test(int value) => Value = value; public double Value { get; } public static explicit operator Test(int value) => new Test(value); public static implicit operator Test(double value) => new Test(value); }}
}How much grief does it cause if you make the double conversion explicit too? Just a random thought.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
How much grief does it cause if you make the double conversion explicit too? Just a random thought.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
Unfortunately, it causes quite a bit of grief. The example I provided was the shortest code I could write to share my pain. Thank you for your thought, but not hoping for an actual solution here...simply ranting :) Regrettably, the actual problem is a lot more complex. It also involves collection initializers, method signature ambiguity, and the entire zoo of built-in numeric data types. I'm helping consumers of a framework avoid the detritus added by explicit casts / constructor invocations. I already have a solution...a separate method signature for each data type (in my code). Its not a huge deal, simply repellant to look at. It also snowballs a bit, to a few places, and forces me to carry test cases for each one. If C# had a different precedence for implicit/explicit, a far more elegant solution would be possible. That, and honestly, it annoys me that it favors an implicit convenience over something I've told it explicitly NOT to do.