>>Hi,
>>Given:

public class A {}
>>public class B
>>{
>>    public static implicit operator B(A a) { return new B(); }
>>    public static implicit operator C(B b) { return new C(); }
>>}
>>public class C {}

Would you find a statement like this too opaque:

C c = (B)new A();

>
>Clear as mud to me Viv <g>
>
>This advice seems the most important:
>
>http://msdn.microsoft.com/en-us/library/z5z9kes2%28v=vs.71%29.aspx
>
>"By eliminating unnecessary casts, implicit conversions can improve source code readability. However, because implicit conversions can occur without the programmer's specifying them, care must be taken to prevent unpleasant surprises. In general, implicit conversion operators should never throw exceptions and never lose information so that they can be used safely without the programmer's awareness. If a conversion operator cannot meet those criteria, it should be marked explicit."

>Once you replace ABC with more descriptive names, I think it will be fine as far as clarity is concerned.
>
>double d = (int)((byte) 32);
>
>although, why I didn't just do
>
>double d = 32;
>
>is beyond me. <g> The descriptive class names do however make it clear what I'm doing.

I think I'm going to make the conversions 'explicit' rather than 'implicit' - purely to enforce bettter readability.
In this instance :
Class A is an EF Entity containing XML from a SQL text field.
Class B imports the XML as an XDocument and provides properties which surface this in easy to access form.
Class C is a lightweight POCO object that holds the values as simple properties without retaining the XDoc.
So, in some ways, B is only there to get from A to C...