Here's a little gotcha that people probably aren't aware of in the RB community. Operator_Convert has a dangerous side-effect.
Class Class1
Dim mData as Integer
Sub Operator_Convert( rhs as Class2 )
mData = Val( rhs.mData )
End Sub
End Class
Class Class2
Dim mData as String
End Class
Dim c1 as Class1
Dim c2 as Class2
c1 = c2
MsgBox Str( c1.mData )
Can you spot the issue?
It's a tricky one -- the problem is that we never instantiated Class2, so it is nil. When we make the c1 = c2 assignment, we are passing in a Nil object. c1's convert doesn't test for it, and so we get a NilObjectException. But you probably expected that. But wait, there's more! (RIP: Billy Mays)
Let's say you check for Nil in the Operator_Convert function and get rid of the exception. Now what? No more unhandled exceptions! Doesn't that strike you as a bit odd? I would expect an exception on MsgBox Str( c1.mData ), yet one doesn't happen!
That's the true scary problem of the convert to operator. Aside from throwing exceptions, there is no way for the call to fail. So even though c1 should be Nil, it won't be.
Thankfully, the Nil chameleon type doesn't act as a Class2 instance in the compiler when it comes to conversion operators. So if you say c1 = Nil, it will be Nil, regardless of the conversion operator. However, I don't recall that as being something explicitly enforced by the compiler so much as it just happening to work that way. I certainly hope that behavior doesn't change, as it would make a bad situation much worse!
Regardless of the behavior of Nil, this insidious problem can still sneak up to bite you if you're not careful. It certainly isn't intuitive behavior that an assignment from a nil object will create a non-nil object when Operator_Convert exists, but create a nil object when Operator_Convert doesn't exist!
I think Mars mentioned this kind of gotcha quite some time a go (either on his old blog or on yours)
They behave like constructors in many ways
The hard part is, as you said, how to deal with getting a nil rhs.
Perhaps raising a NilObjectException is the right behavior so your code for the conversion is like
Sub Operator_Convert( rhs as Class2 )
if rhs is nil the raise new NilObjectException
mData = Val( rhs.mData )
End Sub
Then to use it you do
Dim c1 as Class1
Dim c2 as Class2
try
c1 = c2
MsgBox Str( c1.mData )
catch NOEexc as NilObjectException
end try
At least this way c1 is still nil if c2 is nil which is more consistent with what you might expect to happen
But now your code is littered with try / catch for non-obvious reasons AND the consumers of your classes have to know that you are doing an implicit conversion in places where perhaps you'd like to NOT require anyone to have to know intimate details like that.
And, if you change operator_convert to NOT create a new instance if the parameter is nil that would have it's own set of implications.