www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the story with -property?

reply "Mike" <none none.com> writes:
There's a regression involving `-property` at 
https://issues.dlang.org/show_bug.cgi?id=14564.  In that issue, 
it's stated by a reputable source that `-property` is going away. 
  It was also stated in IRC that it never worked anyway.

So, what's the story on `-property`? Is it going away?  Is the 
regression worth investing time in?

There's also a DMD pull request that, unfortunately, was not 
followed through on: 
https://github.com/D-Programming-Language/dmd/pull/2305

Please advise.

Thanks,
Mike
Jun 27 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 27 June 2015 at 22:55:48 UTC, Mike wrote:

 There's a regression involving `-property` at 
 https://issues.dlang.org/show_bug.cgi?id=14564.  In that issue, 
 it's stated by a reputable source that `-property` is going 
 away.
  It was also stated in IRC that it never worked anyway.

 So, what's the story on `-property`? Is it going away?  Is the 
 regression worth investing time in?

 There's also a DMD pull request that, unfortunately, was not 
 followed through on: 
 https://github.com/D-Programming-Language/dmd/pull/2305

 Please advise.

 Thanks,
 Mike


Definition of property is completely inconsistent. Definition of 
property with -property is also inconsistent. No desire to get 
toward a more consistent position from leadership.

Having 2 definition for the thing is bad for the language as it 
create fragmentation. If I'd had to choose I'd keep the -property 
behavior, but it seems like a lost battle at this point :(
Jun 27 2015
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 27 June 2015 at 22:55:48 UTC, Mike wrote:

 There's a regression involving `-property` at 
 https://issues.dlang.org/show_bug.cgi?id=14564.  In that issue, 
 it's stated by a reputable source that `-property` is going 
 away.
  It was also stated in IRC that it never worked anyway.

 So, what's the story on `-property`? Is it going away?  Is the 
 regression worth investing time in?

 There's also a DMD pull request that, unfortunately, was not 
 followed through on: 
 https://github.com/D-Programming-Language/dmd/pull/2305


It was never intended that -property be kept. It was always 
intended to be temporary. The only question at this point is what 
behavior the compiler will have normally.

Originally, property functions were inferred by the language. The 
compiler would treat any function with no arguments as a getter 
property and any function with a single argument as a setter, but 
this isn't particularly principled, and it allowed nonsense like

     writeln = 7;

Also, you have the problem of a getter property which returns a 
delegate. What does this do?

     foo.delegProp();

It just calls delegProp and does nothing with the return value. 
If you want to actually call it, you have to use two sets of 
parens.

    foo.delegProp()();

And that pretty much destroys the ability to have property 
functions which return a delegate or other callable. So, 
 property was proposed to fix these issues. It would be what was 
used to indicate that a function was a property function, and we 
wouldn't have the compiler inferring property functions anymore. 
So, in theory, it would then be illegal to call an  property 
function with parens (thus ensuring that if parens were used, 
they were used on the return value), and it would be illegal to 
call a normal function without parens, since it wasn't a property 
function anymore. However, this was somewhat controversial (with 
some being _very_ much in favor of it and others not being very 
happy about it), and more importantly, it was a breaking change. 
So, when  property was introduced, it didn't do much of anything. 
It was going to at some point, but it didn't then. So, later, in 
order to combat the issue with breaking changes, -property was 
introduced with the idea that it would have property enforcement, 
and we'd have the chance to iron it all out there before making 
the compiler act that way all the time.

However, -property did only partial property enforcement. It just 
made it so that you couldn't call a normal function with parens. 
It did nothing to ensure that an  property function was called 
without parens. And it was never completed, leaving  property as 
doing almost nothing normally and -property not really doing its 
job ( property does affect some aspects of compile-time 
introspection such as typeof but outside of -property, it has 
_no_ effect on how functions are called).

And this controversial issue only got worse when we added UFCS to 
the language rather than just supporting the member call syntax 
with arrays, because then all of a sudden, folks were writing 
code like

     auto foo = range.map!(a => a % 100)();

And they thought that the extra parens on templated functions 
like map were ugly, so people started doing stuff like

     auto foo = range.map!(a => a %100);

So, the idea that enforcing that non-property functions be called 
with parens became less and less popular - and remember that 
that's the only thing that -property actually checks right now. 
Also, arguments on  property never went anywhere useful, because 
there were folks on both sides of the argument (and several spots 
in between), and many felt very strongly on the issue. In 
addition, Andrei has never liked the idea of  property, so 
nothing really ever happened, and we've gotten less and less 
willing to break code as time has gone on, meaning that the 
willingness to switch to full property enforcement (or even 
partial property enforcement) has decreased as well.

The _most_ that we could get at this point would be to have it 
enforced that  property functions be called without parens 
without requiring that non-property functions be called with 
parens (UFCS has simply made it too popular to leave off the 
parens) and possibly requiring that  property be used in order to 
use the property setter syntax. However, even that would break 
code, so it's questionable as to whether that would occur. It's 
almost a guarantee that  property will at some point affect 
functions which return callables and interpret their first set of 
parens as calling their return value, since without that, we 
can't treat functions which return callables as property 
functions, but beyond that, it's an open question as to whether 
any kind of property enforcement will ever be in place.

Regardless, as it's a guarantee at this point that we're not 
going to require parens on normal functions, -property is 
currently enforcing something that we don't intend to ever 
enforce. So, there is no reason to ever use it. We would have 
dropped it anyway once it was fully ironed out, and we were 
migrating its behavior into the language proper, but at this 
point, pretty much the only reasons that it exists are to avoid 
breaking the build process of anyone using it, and because no one 
has removed it. Really, it should be changed to do nothing 
(except maybe print a message about going away) as the initial 
change so that it doesn't break anyone's build process, and we 
don't have to support it.

We _were_ building Phobos with it to avoid breaking folks code, 
but clearly, we stopped, because we have that regression now. So, 
I think that we need to either build Phobos with -property again 
and fix the regression (so that we don't break other people's 
code), or we need to change the compiler so that -property does 
nothing except print a message that the -property flag has been 
deprecated and does nothing.

- Jonathan M Davis
Jun 27 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, 28 June 2015 at 00:25:47 UTC, Jonathan M Davis wrote:

 [snip]
 it's an open question as to whether any kind of property 
 enforcement will ever be in


I should probably note that a long term consequence of not having 
full property enforcement is that whether parens are used or not 
in generic code is going to be a problem. For, instance,

     template isInputRange(R)
     {
         enum bool isInputRange = is(typeof(
         (inout int = 0)
         {
             R r = R.init;     // can define a range object
             if (r.empty) {}   // can test for empty
             r.popFront();     // can invoke popFront()
             auto h = r.front; // can get the front of the range
         }));
     }

requires that empty and front be called without parens, which 
means that front and empty can be enums or variables or anything 
else which is going to fit the syntax in the code above and not 
just functions. So, you can't _ever_ be calling front or empty 
with parens in generic code if you want your code to work with 
ranges in general rather than the small set of ranges that you 
might be using at the moment. But the compiler doesn't enforce 
that right now at all. It just enforces that the ranges 
themselves be such that front and empty be usable without parens.

In addition, it requires that popFront be used _with_ parens, but 
the only case where it would break code if you didn't would be if 
someone had declared popFront as callable rather than a function, 
since using it without parens as a function would work - but not 
as callable. Now, realistically, pretty much no one is going to 
do that, but technically, according to the API requirements, it's 
perfectly legitimate to do so, and the compiler doesn't protect 
against anyone from writing code which calls popFront without 
parens.

Full property enforcement would fix these issues, but we're never 
going to get it. So, we will always have to worry about generic 
code which uses parens where it shouldn't or doesn't use them 
where it should. How big an issue this will be is an open 
question, but being lax with syntax (like we are with parens on 
functions) doesn't jive well with generic code, so it's something 
that we're going to have to watch out for.

- Jonathan M Davis
Jun 27 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 28 Jun 2015 00:36:41 +0000, Jonathan M Davis wrote:


 Full property enforcement would fix these issues, but we're never going
 to get it.


i must admit that Kenji's patch (referred by OP) is the best solution i've=20
seen. it fixes the most annoying thing with delegate properties, and it=20
can be easily tuned to emit a warning or deprecation on calling=20
properties with "()". i incorporated that patch in my fork and did=20
exactly that: turned errors to warnings. and i must say that i'm still=20
able to compile majority of D code without any problems. and i found some=20
invalid "front" usage in Phobos by the way (aka `front()`).

also, warning warns about "()()" on delegate property, or about "()" on=20
delegate property, depending of module being marked as "modern" or not.=20
so far i found zero problems with it.

yet the patch seems to be rejected by W&A without any sane reason. ah,=20
yes, the thing that *can* cause same havok was pointed by Kenji himself
[1]. i hit it once or twice, and it's still solvable with warning and=20
deprecation cycle.


[1] https://github.com/D-Programming-Language/dmd/
pull/2305#issuecomment-20657962=
Jun 28 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/28/15 10:25 PM, ketmar wrote:

 and i found some
 invalid "front" usage in Phobos by the way (aka `front()`).


Have you filed an issue for this? If not, please do.

-Steve
Jun 30 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 30 Jun 2015 08:03:00 -0400, Steven Schveighoffer wrote:


 On 6/28/15 10:25 PM, ketmar wrote:

 and i found some invalid "front" usage in Phobos by the way (aka
 `front()`).


=20
 Have you filed an issue for this? If not, please do.


oops. sorry, i simply bolted a fixes in my branch and forgot about that=20
(actually, noting "fill a bug later"). i'll go thru it in weekend to see=20
what is left unfixed and will fill a PR.

tnx for reminding me about that.=
Jun 30 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
"will open a ticket", i meant. ;-)=
Jun 30 2015
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Saturday, 27 June 2015 at 22:55:48 UTC, Mike wrote:

 There's a regression involving `-property` at 
 https://issues.dlang.org/show_bug.cgi?id=14564.  In that issue, 
 it's stated by a reputable source that `-property` is going 
 away.
  It was also stated in IRC that it never worked anyway.

 So, what's the story on `-property`? Is it going away?  Is the 
 regression worth investing time in?

 There's also a DMD pull request that, unfortunately, was not 
 followed through on: 
 https://github.com/D-Programming-Language/dmd/pull/2305

 Please advise.

 Thanks,
 Mike


http://wiki.dlang.org/Property_Discussion_Wrap-up
Jun 28 2015