www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is the -property compiler flag broken/bad idea?

reply "Gary Willoughby" <dev kalekold.net> writes:
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.
Jun 05 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 05 2013
parent "Gary Willoughby" <dev kalekold.net> writes:
 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.
Jun 05 2013
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 05 2013
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 05 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
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.
Jun 05 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 05 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 05 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 05 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 05 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 05 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jun 05 2013
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
Sorry I don't get it. Are you for or against optional parenthesis 
for function which are not marked with  property?
Jun 05 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jun 05 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 05 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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!
Jun 05 2013
parent reply "Diggory" <diggsey googlemail.com> writes:
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.
Jun 06 2013
parent reply "Martin Primer" <megaboo zoo.com> writes:
What would be good is:

 property int foo {
     get() {
         _val = value;
     }
     set() {
         value = _val;
     }
}

usage:

foo = 12;
int bar = foo;


my 2 cents.
Jun 06 2013
parent "Diggory" <diggsey googlemail.com> writes:
On Thursday, 6 June 2013 at 10:38:27 UTC, Martin Primer wrote:
 What would be good is:

  property int foo {
     get() {
         _val = value;
     }
     set() {
         value = _val;
     }
 }

 usage:

 foo = 12;
 int bar = foo;


 my 2 cents.
That's both much more limited and longer than the current syntax. It also turns properties from a simple rewrite rule into a full language feature, and it doesn't seem to give any benefits?
Jun 06 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jun 05 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 05 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 5 June 2013 at 22:25:21 UTC, Adam D. Ruppe wrote:
 3) prop += 5 and friends
This is the biggest deal for me. Being able to write all these read-modify-write operators on properties would simplify writing transparent wrapper types so much.
Jun 06 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 05 Jun 2013 17:36:11 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 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.
I think any solution has to disallow setter syntax on arbitrary functions. Anything else is up for debate IMO. And I've come to the point where I don't care, as long as SOMETHING is decided. One other sticky point is UFCS properties. -Steve
Jun 06 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 05 2013
prev sibling parent "nazriel" <spam dzfl.pl> writes:
On Wednesday, 5 June 2013 at 18:09:30 UTC, 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.

 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.
It is useful as "get that ruby out of my code" warning ;)
Jun 06 2013