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

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 :(

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

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

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

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 seen. it fixes the most annoying thing with delegate properties, and it can be easily tuned to emit a warning or deprecation on calling properties with "()". i incorporated that patch in my fork and did exactly that: turned errors to warnings. and i must say that i'm still able to compile majority of D code without any problems. and i found some invalid "front" usage in Phobos by the way (aka `front()`).

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

yet the patch seems to be rejected by W&A without any sane reason. ah, 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 deprecation cycle.


[1] https://github.com/D-Programming-Language/dmd/ pull/2305#issuecomment-20657962

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

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()`).
> 
> 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 (actually, noting "fill a bug later"). i'll go thru it in weekend to see what is left unfixed and will fill a PR.

tnx for reminding me about that.

"will open a ticket", i meant. ;-)