On DIP 23

[Robert]

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.