[fauigerzigerk]

The syntactical distinction makes us believe that there is a technical difference as well, but that is not the case. I find that misleading. If properties don't give us any technical guarantees, then a naming convention as in Java seems more appropriate to me.

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.

[breischl]

I think disguising a simple function call as a variable access is sensible. But yes, people can disagree on this. I think the C# and Java designers are probably all smart people who thought about this a lot more than the two of us. :)

>>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.

[int_19h]

I think it's a reference to this:

"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.