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 


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.



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:


 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