Isn't the compiler smart enough to detect UFSC and enable then optional parenthesis and force they otherwise, except the function is already marked with @property?
That would be a good midway.
But I just wonder: Is this really important enough to do this in the near future? I know so much other things, which seems far more important, like improving the GC, fixing AA, implements rvalue references, decide whether function should be default final / virtual and so on and so on.

On Wednesday, 5 June 2013 at 21:36:26 UTC, Jonathan M Davis wrote:
> Walter and Andrei pretty much consider
> @property to have been a failure and seem to want to get rid of @property and go to pretty much what we had before.

Blah I hope that doesn't happen.

I'm the author of the quoted bit in the OP, and have made my hatred of -property well known in the past.

But, I probably wouldn't even loathe -property so much if it actually *worked*, that is, solved the problem(s) that led to @property's introduction in the first place:

1) returning especially callables (property_name() should call the return value, not the function)

2) ambiguous type/reference given function_name (is typeof(property_name) the type of the function or the type of the return value? For @properties, I say it should be the latter, for other functions, the former)

3) prop += 5 and friends


When -property first came out, I was actually kinda excited for it. Finally, my JavascriptObject code could work as intended! Sure, it'd be a hassle to fix stuff like my dom.d code that uses optional parens a lot, but it'd be worth it if that dynamic type code worked correctly.

...Then I tried it, and it fixed nothing. So when it broke dom.d even more than I thought, and the years passed, yes it has been years now, and it still fixed nothing, it just became completely dead to me.


BUT, and this is important, items #1, #2, and #3 are *still* problems! That's what @property can and should fix. Throwing it away entirely is a step in the wrong direction.

Sorry I don't get it. Are you for or against optional parenthesis for function which are not marked with @property?

On Wednesday, 5 June 2013 at 22:31:15 UTC, Namespace wrote:
> Sorry I don't get it. Are you for or against optional parenthesis for function which are not marked with @property?

I'm for optional parens, but I'm also for @property, because the problems @property ought to be fixing are semantic, not syntax, and have no impact at all on non-@property functions.

The questions of @property and optional parens actually have nothing to do with each other, besides the unfortunate fact that they come up together in these threads and -property confuses the two. Optional parens is a feature of function call syntax. @property is about making a function look like a variable to the outside world, which means that function call syntax shouldn't apply to it anymore either way.

On Thursday, June 06, 2013 01:00:12 Adam D. Ruppe wrote:
> On Wednesday, 5 June 2013 at 22:31:15 UTC, Namespace wrote:
> > Sorry I don't get it. Are you for or against optional parenthesis for function which are not marked with @property?
> 
> I'm for optional parens, but I'm also for @property, because the problems @property ought to be fixing are semantic, not syntax, and have no impact at all on non-@property functions.
> 
> The questions of @property and optional parens actually have nothing to do with each other, besides the unfortunate fact that they come up together in these threads and -property confuses the two. Optional parens is a feature of function call syntax. @property is about making a function look like a variable to the outside world, which means that function call syntax shouldn't apply to it anymore either way.

Which is essentially the position of weak property enforcement. Property functions must be used as properties, but non-property functions are free to be called without parens.

- Jonathan M Davis

On Thursday, June 06, 2013 00:25:20 Adam D. Ruppe wrote:
> BUT, and this is important, items #1, #2, and #3 are *still* problems! That's what @property can and should fix. Throwing it away entirely is a step in the wrong direction.

I don't disagree, but an appropriate proposal has to be accepted, and Walter and Andrei seem to be leaning towards throwing away @property entirely.

- Jonathan M Davis

On Wed, Jun 05, 2013 at 08:08:16PM -0400, Jonathan M Davis wrote:
> On Thursday, June 06, 2013 01:00:12 Adam D. Ruppe wrote:
> > On Wednesday, 5 June 2013 at 22:31:15 UTC, Namespace wrote:
> > > Sorry I don't get it. Are you for or against optional parenthesis for function which are not marked with @property?
> > 
> > I'm for optional parens, but I'm also for @property, because the problems @property ought to be fixing are semantic, not syntax, and have no impact at all on non-@property functions.
> > 
> > The questions of @property and optional parens actually have nothing to do with each other, besides the unfortunate fact that they come up together in these threads and -property confuses the two. Optional parens is a feature of function call syntax. @property is about making a function look like a variable to the outside world, which means that function call syntax shouldn't apply to it anymore either way.
> 
> Which is essentially the position of weak property enforcement. Property functions must be used as properties, but non-property functions are free to be called without parens.
[...]

IMO, this is needless conflation of the need for properties (function(s) that behave as though they were class/struct variables) and calling functions without parens. I'm a bit disappointed that the big long discussion on @property in the main D forum turned out to be 50% confusion over these two distinct issues, and 50% in-fighting that left no real conclusion as to how to implement @property correctly.

I was hoping for a clean way for functions to imitate class/struct variables via @property, independently of whether or not non-@property functions are allowed to be called without parens. But alas, it was not to be. :-/


T

-- 
May you live all the days of your life. -- Jonathan Swift

On Wednesday, June 05, 2013 17:12:38 H. S. Teoh wrote:
> I was hoping for a clean way for functions to imitate class/struct variables via @property, independently of whether or not non-@property functions are allowed to be called without parens. But alas, it was not to be. :-/

Part of the problem is that it's pretty much impossible to do completely. You'll never be able to make it so that swapping between variables and property functions (in either direction) is guaranteed to not break code. So, the question becomes at what level you attempt it.

And it's not necessarily the case that @property is dead. It's strict property enforcement which is definitely dead (in which case, there would have been no optional parens). What exactly is going to happen with @property is not clear, but given what -property does, there's pretty much no way that -property is sticking around (not with its current semantics anyway). We may yet end up with @property giving us something (like a way to deal with having a property return a delegate cleanly), but it _is_ true that Walter and Andrei are leaning towards axing it entirely. And unfortunately, to resolve it, we're bound to need another long discussion on the topic. But it'll probably help if such a discussion starts with the premise that we are not going to do anything to restrict optional parentheses. Since without that, the discussion will degrade pretty quickly.

- Jonathan M Davis

On Thursday, 6 June 2013 at 00:08:31 UTC, Jonathan M Davis wrote:
> Which is essentially the position of weak property enforcement.

Yes, though I wish we would stop calling it 'enforcement' because nothing actually needs to be especially enforced if we do it right!

@property int foo();

foo(); // error, type int is not callable

@property void delegate() foo();

foo(); // works, calls the returned delegate.


This isn't a syntax case in the parser looking at syntax, it is a natural consequence of the @property function call being substituted for its return value.

Similarly btw:

&foo; // error, foo is not an lvalue

because foo here is a returned int or whatever. This isn't directly substitutable for a plain "int foo", but that's ok because one benefit of properties is we get to do things regular members can't, like restrict read or write access like this.

@property ref int foo();

static assert(is(typeof(foo) == int));
static assert(is(typeof(&foo) == int*));

foo = 10; // ok

that works now because ref int is an lvalue. An @property returning a reference is one case were we should be able to get (almost*) 100% substitution between it and a regular member variable.

* __traits(propertyImplementation, foo) or something like that might still show something different, but if you're using that kind of thing, it is clear that you want special access anyway.



I've tried to implement this in the compiler before. It seems like it would be a simple case of a semantic rewrite of "foo" into "foo()" iff foo is @property as soon as you see it. But the implementation is hard because of things like setters. foo = 10 should be rewritten into foo(10), but that's easier said than done - it either has to undo the foo->foo() rewrite on the left hand side, then look for the matching setter, or the rewrite has to be moved.... and moving it means duplicating it in all the bazillion places it can be referenced.

So my attempt got 90% to where I wanted pretty easily, but that last 10% is a hell of a bump in the road and I haven't figured it out yet. A working pull request would surely be a big step toward closing this discussion once and for all, I wish I had more free time, I have so  much D I want to hack on!

On Thursday, 6 June 2013 at 00:56:22 UTC, Adam D. Ruppe wrote:
> On Thursday, 6 June 2013 at 00:08:31 UTC, Jonathan M Davis wrote:
>> Which is essentially the position of weak property enforcement.
>
> Yes, though I wish we would stop calling it 'enforcement' because nothing actually needs to be especially enforced if we do it right!
>
> @property int foo();
>
> foo(); // error, type int is not callable
>
> @property void delegate() foo();
>
> foo(); // works, calls the returned delegate.
>
>
> This isn't a syntax case in the parser looking at syntax, it is a natural consequence of the @property function call being substituted for its return value.
>
> Similarly btw:
>
> &foo; // error, foo is not an lvalue
>
> because foo here is a returned int or whatever. This isn't directly substitutable for a plain "int foo", but that's ok because one benefit of properties is we get to do things regular members can't, like restrict read or write access like this.
>
> @property ref int foo();
>
> static assert(is(typeof(foo) == int));
> static assert(is(typeof(&foo) == int*));
>
> foo = 10; // ok
>
> that works now because ref int is an lvalue. An @property returning a reference is one case were we should be able to get (almost*) 100% substitution between it and a regular member variable.
>
> * __traits(propertyImplementation, foo) or something like that might still show something different, but if you're using that kind of thing, it is clear that you want special access anyway.
>
>
>
> I've tried to implement this in the compiler before. It seems like it would be a simple case of a semantic rewrite of "foo" into "foo()" iff foo is @property as soon as you see it. But the implementation is hard because of things like setters. foo = 10 should be rewritten into foo(10), but that's easier said than done - it either has to undo the foo->foo() rewrite on the left hand side, then look for the matching setter, or the rewrite has to be moved.... and moving it means duplicating it in all the bazillion places it can be referenced.
>
> So my attempt got 90% to where I wanted pretty easily, but that last 10% is a hell of a bump in the road and I haven't figured it out yet. A working pull request would surely be a big step toward closing this discussion once and for all, I wish I had more free time, I have so  much D I want to hack on!

That would be good - some breakage could be avoided by checking if the return type of the property implements the function call operator, if it doesn't you could accept the "getter()" syntax with only a warning/deprecation message.