Here's a C# link providing a definition of property http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx
The C# implementation appears to fit closer with the namespace concept that had been proposed as solution to the property question, it is clearly not the same thing as the @property concept.
In the C# case, it may be a bit clearer when to use the property construct because in one shot you are defining both the variable instance and the way it is accessed, i.e., it may help somewhat with organizing your code, if there's scoping rules restricting access, that may help too.
In the D case, you must always define the variable instance outside the property scope, and then create a getter and setter for it separately. This is the usual way of doing things, with the only exception that when tagged with @property you can use the assignment syntax, so for the most part its only a question of what calling syntax is more convenient to use, assignment or regular function call syntax.
I can see an advantage that would make the situation a whole lot clearer. If internal to a stuct or class, you are accessing the local member variable directly, but later decide to wrap it so that it cannot be accessed directly (unfortunately this is impossible in D because of the way scoping works), you could rename the variable and wrap it into a property, and all your internal code will continue to work (but this depends on what you were doing with it).
Externally, I never make variables directly accessible (unfortunately in D this is not 100% possible due to scoping rules, eg private has no effect inside a module), so there's not much value to the property concept in my case because I'll only very rarely switch from a variable to a function wrapper. For me, I have to decide if the assignment syntax is more convenient or not, and that's all I have to go with when making a decision.
It would be far more useful to have a namespace implementation, because then I could 100% hide access to a variable, and that would make using such a facility much more clear, ie., it becomes a question of accessibility vs a matter of purely syntactic taste.
Without a clear purpose behind it, the @property concept buys me virtually nothing but syntactic sugar, except in the rare case where I may want to wrap a variable into a function after using it directly for a while, but even that is weak because the wrapper is a very leaky one, i.e,, you cannot 100% enforce access to go through the getter and setter from inside the struct and the module where it is used, and it does nothing in terms of helping me to define the wrapper scope, ie. there's no organizational advantages of grouping things together under one wrapper, and my code looks the same no matter if I use property or not.
In summary, it seems to me that where there is an advantage, it's very weak and very rare, so for the most part it's a feature that boils down to if I want to use the assignment syntax or not. I don't think that was the intention of @property, but that's how I see it.
For me, the optional approach is more flexible and does the exact same job as @property proposal. I can easily wrap a variable without specifying @property and get the same job done, and I can choose which syntax is more convenient at a later date and change it depending on the context.
If you want a more clear case for properties, then limiting access through scoping should come into the equation, as well as giving the programmer a better means to structure and organize the code around wrappers. @property does not help with any of this.
My opinions are based on actual attempts to use @property in production code and I found little use for it.
Have you tried to use it under real world situations? --rt
