I've been using the -property compiler flag when i compile programs and thought it was pretty cool but i've recently had a conversation with someone who has informed me it's broken and a bad idea.

> Never, ever, ever use -property. Its implementation is totally wrong
> and based on a flawed idea to begin with. Using it just breaks good
> code and gives nothing in return. From the ng discussions looks like
> I'm going to get my way soon and it will be removed and buried like it
> deserves. If you remove that, everything else works.

Can someone point me to the discussion on this or quickly fill me in as to why this is the case. I have no opinion on the subject as i'm ignorant of this topic.

Thanks.

On Wednesday, June 05, 2013 20:09:29 Gary Willoughby wrote:
> I've been using the -property compiler flag when i compile programs and thought it was pretty cool but i've recently had a conversation with someone who has informed me it's broken and a bad idea.

There have been quite a few discussions on properties. I believe that this was the last major one:

http://forum.dlang.org/post/kdqrnl$13ft$1@digitalmars.com

You probably don't want to read it. It's huge. I'll try and summarize the situation. Historically, in general, if a function had no parameters and returned a value, you could call it without parens, and if a function only had one parameter, then you could use the = syntax with it. Some folks wanted stricter control over that behavior, and it did cause some problems with stuff like functions that returned delegates. If foo were a function that returned a delegate, and you wanted to call the delegate without assigning it to something first, you had to do foo()() instead of foo(). foo and foo() were identical. To fix this, @property was introduced.

The idea behind @property was that if you wanted a function to use the property syntax, you had to mark it with @property, and functions which didn't have @property couldn't use the property syntax. That would be strict enforcement of properties. -property was introduced in an effort to sort out the compiler logic required for that enforcement and provide a transition process. However, that's where the problems begin.

First off, -property was never fully implemented. All it does is scream at you if you call a non-property function without parens. It doesn't complain if you call a property with parens, which means that it didn't yet solve the delegate problem.

Second, a number of people didn't want strict property enforcement. Many of them wanted weak property enforcement - specifically they wanted it to be enforced that @property functions be called without parens (fixing the delegate problem) but that any non-@property function could be called without parens if you wanted to (per the original logic for that pre-dated @property and has never actually been removed from the language).

Third, some people (like Andrei) never really liked @property in the first place for a variety of reasons.

Fourth, with the advent of UFCS, many more people started really wanting to leave the parens out, because they don't like it when you have to use parens with both the template argument and the function argument when there is no function argument. e.g. range.map(a => a * 3)() or range.filter(a => a < 5)(). With option parens, you could do range.map(a => a * 3) and range.filter(a => a < 5) instead, which many people found to be more aesthically pleasing.

So, property enforcement (which had never been properly implemented even with -property let alone as the normal behavior) became increasingly unpopular. And at this point, it's crystal clear that optional parens are _not_ going away.

At this point, -property specifically gives an error when optional parens are omitted (in fact, that's all it does right now). So, the behavior that it's testing for is behavior which has been determined to acceptable if not outright desirable, meaning that using -property makes no sense. And I would expect it to go away (or at least stop doing anything) in the near future: http://d.puremagic.com/issues/show_bug.cgi?id=10143

Now, the exact future for @property isn't entirely clear at the moment, but I think that one of three scenarios is likely:

1. It's gotten rid of entirely, in which case we just retain the original behavior. And at this point, most people seem to be fine with just putting up with the delegate behavior rather than dealing with @property anymore.

2. @property is retained but really only has an effect on getter functions which return delegates in order to solve the delegate problem.

3. @property is retained but is only used to define which functions can be used as setters (so we have enforcement on setters but not getters). This could be combined with #2.

But regardless of what exactly happens, @property will be far more restricted than originally planned (if it exists at all), and -property will be gotten rid of.

- Jonathan M Davis

I use @property consistently because I think it is absolutely ugly and confusing to call functions without brackets or to mix both versions. But I also use UFCS as good as never (I don't like it that much)
And as long as there is the possibility to enable a strict behavior with @property and -property I will continue using it. If this control get lost, that would really be a shame and would lead in inconsistent behavior and confusion.

Just my 2 cents.

On Wednesday, 5 June 2013 at 20:43:54 UTC, Namespace wrote:
> I use @property consistently because I think it is absolutely ugly and confusing to call functions without brackets or to mix both versions.

To specify this point:
I think it's ugly and confusing to be able to call *all* functions without brackets. If I (or someone else) think it is appropriate I (he) should mark such functions explicit with @property.

I had a better proposal:

http://forum.dlang.org/thread/rftboygivwmwizeywygm@forum.dlang.org optional parens everywhere except last position of function chain.

This makes it visually unambiguous what is a function vs function call and avoids all but last parens, makes @property/(-property) obsolete, and makes &foo operator un-necessary.

snippet:

When a,b,c are non-property functions:
a.b.c(); => a().b().c(); // c is called
a.b.c; // c function not called


What do you guys think?

On Wed, Jun 5, 2013 at 1:47 PM, Namespace <rswhite4@googlemail.com> wrote:

> On Wednesday, 5 June 2013 at 20:43:54 UTC, Namespace wrote:
>
>> I use @property consistently because I think it is absolutely ugly and confusing to call functions without brackets or to mix both versions.
>>
>
> To specify this point:
> I think it's ugly and confusing to be able to call *all* functions without
> brackets. If I (or someone else) think it is appropriate I (he) should mark
> such functions explicit with @property.
>

And what if I like to write a property getter?

@property
float x() const pure nothrow { ... }

@property
void x(float x) { ... }

This should still be possible, otherwise you will not convince me.

> You probably don't want to read it. It's huge. I'll try and summarize the situation.
>
> - Jonathan M Davis

Thanks for a great overview, that's cleared things up nicely.

On Wednesday, June 05, 2013 22:43:53 Namespace wrote:
> I use @property consistently because I think it is absolutely ugly and confusing to call functions without brackets or to mix both versions. But I also use UFCS as good as never (I don't like it that much)

I tend to agree, but the general consensus is in favor of having optional parens. Too many people like UFCS and don't like having to have two sets of parens for all of the templated functions.

> And as long as there is the possibility to enable a strict behavior with @property and -property I will continue using it. If this control get lost, that would really be a shame and would lead in inconsistent behavior and confusion.

Strict property enforcement is as good as dead. -property is still there for the moment, but its days are numbered. 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. _Exactly_ what we're going to end up with isn't clear at the moment, but it's crystal clear that strict property enforcement will never happen, because it's too unpopular.

- Jonathan M Davis

This is really sad. I think that's almost as big a mistake as the lack of rvalue references ( I know you say it will come one day, but don't lie to yourself ;) ).
The question is, how much the public will like it, if D should ever become popular.
Anyway, this is IMO a huge mistake, to not offer even the possibility of strict 'property' use.

On Wednesday, June 05, 2013 13:55:30 Timothee Cour wrote:
> I had a better proposal:
> 
> http://forum.dlang.org/thread/rftboygivwmwizeywygm@forum.dlang.org optional parens everywhere except last position of function chain.
> 
> This makes it visually unambiguous what is a function vs function call and avoids all but last parens, makes @property/(-property) obsolete, and makes &foo operator un-necessary.
> 
> snippet:
> 
> When a,b,c are non-property functions:
> a.b.c(); => a().b().c(); // c is called
> a.b.c; // c function not called
> 
> 
> What do you guys think?

IIRC, that wasn't a particularly popular suggestion. The folks who want optional parens want optional parens for _all_ of the calls - including the last one. I'd be surprised if Walter or Andrei were in favor of it.

Personally, I don't see much point in forcing parens on the last call when you've already made them optional on all of the others. From the standpoint of someone who doesn't like optional parens, the damage has already been done, and for those who want optional parens, it's undesirable, because those parens aren't optional.

- Jonathan M Davis