Oops. I kinda missed the complete discussion about this. I am sure someone else already wrote something similar, so just ignore the post.

Best regards,

Robert

On Wed, 2013-02-06 at 23:10 +0100, Robert wrote:
> Well first what I like about it: The approach function symbols are handled, it is a pretty clear concept:
> 
> void f() {
> }
> 
> f;
> 
> f is a function, you can take the address of it and call it and that's it. So if you just write it down, it makes sense that it gets called. Not so for delegates, function objects, ... Sounds sane to me, I like it.
> 
> About properties:
> 
> In short, I died a little reading it.
> 
> I know we have UFCS, but @properties are meant to emulate a field, so the semantics should be as close to a field as possible. Ideally, identical.
> 
> Especially the part about module level properties made me crazy:
> @property double fun(int x, double y) { assert(x == 42 && y == 43);
> return y; }
>     42.fun = 43;
> 
> reads to me: The integer 42 has a property called fun, which gets assigned 43???
> 
> If we special case properties, we might as well disallow UFCS for them, which makes sense, because you can not define a field external to an object either.
> 
> So the proposal for module level properties, would be right exactly the
> other way round (emulating global variables):
> private int myCoolSetting_;
> @property int myCoolSetting() {
> 	return myCoolSetting_;
> }
> @property void myCoolSetting(int setting) {
> 	enforce(setting>0 && setting<10, "Invalid setting!");
> 	myCoolSetting_=setting;
> }
> 
> myCoolSetting=8; // Ok.
> 
> That is what properties are all about.
> 
> The part, about taking the address of a property, is fine as long as we allow fields to be declared with @property as I already suggested, with the following semantics:
> 
> @property int a;
> 
> would be lowered to:
> 
> private int __a;
> 
> @property void a(int a_) {
> 	__a=a_;
> }
> 
> @property int a() {
> 	return __a;
> }
> 
> in order to ensure that @property declared fields and properties declared as functions do really have the same semantics.
> 
> If you don't think about properties as fields, than I understand Walters suggestion about removing @property completely and we could as well do it.
> 
> UFCS with properties, makes little to no sense. Because well the name already suggests: "Uniform Function Calling Syntax", properties are not about calling functions. Allowing UFCS would offer the possibility of adding some kind of dynamic properties/fields to an object, but the code samples with integers and especially the problem with module level properties suggests that this causes more problems than it is worth.
> 
> properties -> no UFCS and we have a sane world!
> 
> Best regards,
> 
> Robert
> 
> P.S.: Things like int a = 4.2.truncated;
> 
> do make sense, but UFCS and optional parentheses would do the trick too, so no need to abuse properties there.
> 
> 
>