And if you look at the guidelines I linked to, you'll see that the criteria that are supposed to tell us whether or not to use a property are much more subtle than making a network call vs accessing a field. Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?
I think disguising a function call as a direct variable access is much more problematic than calling a function that may or may not do more than return the value of a variable.
That said, I do realize that reasonable people can absolutely disagree on this issue.
>>Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?
I just quickly re-read that page, but I don't see what you're referring to here.
"The operation is a conversion, such as the Object.ToString method."
But this only pertains to the conversion of the object on which the property is defined. In other words, you should have methods like ToString or AsEnumerable, rather than properties like String or Enumerable, even though other rules would indicate property to be valid (idempotent, fast, no arguments). This rule is just an indication that properties represent conceptual attributes of an object; and the result of a conversion of an object to something else is not an attribute.
And if the implementation of a C# property changes in any of the ways that would make it a method, that probably deserves to be surfaced as a breaking change in the API. That's a feature, not a bug. eg, I would certainly want to know if the implementation of a property was changed from a field access to a network call.