Implicit Conversion Operators and Value Types

Folks,

I’ve come across this blog article: Implicit Conversion Operators are Bad. The article discourages the use of implicit conversion with reference types. In the beginning, the article has got this statement:

Quote:

---

Implicit conversion operators are incredibly important to the language, but only for value types. [emphasis original]

---

Then the article goes on to describe problems caused by implicit conversions of reference types (which I understand, I think). The article doesn’t explain how to use implicit conversion with value types. This is what I’m wondering about. My present thinking is this:

• The conversion operator is on a value type, and it returns a value type. Implicit - okay.
• The conversion operator is on a reference type, and it returns a value type. Implicit – okay.
• The conversion operator is on a value type, and it returns a reference type. (That would be a somewhat bizarre, but would it be wrong?) Implicit – not okay.
• The conversion operator is on a reference type, and it returns a reference type. Implicit – not okay.

If it returns a value type, an implicit conversion operator is okay on both value type and reference type.
If it retirns a reference type, implicit conversion is not okay.

Is this correct? Is this complete?

Any suggestion, insight or reference is really appreciated!

Cheers,
- Nick

P.S. For the most part, I work mostly with C and C++, where I have fine control over things like const, pointers, references. Of course, that comes at a risk of having nasty pointer-related bugs.

Define 'Bad'.

To me, it's in the context of what I'm doing. For the work that I've done so far, implicit conversions have never been an issue.

If I experienced a performance issue, I would profile and make necessary adjustments.

Otherwise, I'm going to let .Net do its thing.

well i liked the article

in general the whole point of the article could have been sumed up to
rule of thumb
don't use implicit operators on references
use explicit operators or conversion methods on references

he makes some good points to back it up as well

Quote:

---

That said, to what value would this evaluate?
object.ReferenceEquals(wrapper, earlGray);

---

though that said your average programmer probably is not using that
then again a new programmer might be using it correctly.

either way we shouldn't miss his point's or dismiss it.
which although he maybe didn't state so well
implicit conversion from one reference to another can be dangerous down the road

to try explain it simply from another angle ill try to state his case as
what we expect vs what we could end up with

ok so lets say we have two types A and B
they could be value or ref....
(we should expect a slightly different behavior from each)

A a;
in the case of a value you could also imagine this a= or a.feild = something;
in the case of a reference you might imagine this a = new A(something);
then we have another reference or value B
B b;
so whats the differences, right off the bat
what should we should expect if the above is reference type or value type.

below with a reference type both point to the same memory location
though there are two separate references they point to the same location
b = a;
below with a value type both do not point to the same location
there are two copy's at two different locations containing the same value
b = a;

so his first point is
behaviorally if you change the implicit operators for reference types
or cause them to act as though it is a value behaviorally
by using implicit operators
then, with a reference type, the behavior expected of a = b doesn't work the same
ergo
pointing to the same memory location like it/you would expect it should
instead
you get, two refs, that point to two different locations, with the same values
someone might come along to use it like every other reference they are used to
but now it works like a value
they dont' know why... they get bugs... they cant figure it out... = arggahhh
soooo he's saying.... that's bad... and ya in general he's right it is.

his second point is
if we did have to use a class...
then to convert to say a value or another reference type
we should have a method that makes it explicitly obvious
so then the way to do that is to not actually use the implicit operator :)
n instead make a method that makes it clear
or use a (explicit operator) ? to cast i dunno
point is make it so at least its somewhat clear what is being done

My resume for this thread.

The original post had this hypothesis:

Quote:

---

If it returns a value type, an implicit conversion operator is okay on both value type and reference type.

---

The hypothesis withstood the peer review.

P.S. This question was also mirrored here.