Thread overview
[Issue 7723] New: @property filter/filter
[Issue 7723] @property filter/map
Mar 20, 2012
Jonathan M Davis
Mar 21, 2012
Jonathan M Davis
Mar 21, 2012
Jonathan M Davis
Mar 21, 2012
Adam D. Ruppe
March 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7723

           Summary: @property filter/filter
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2012-03-18 05:51:03 PDT ---
I suggest to turn filter and map into @properties, so thanks to UFCS you are allowed to use them like this, that is quite handy:

[1, 2, -3, 4].filter!(x => x > 0).map!(x => x ^^ 0.2).writeln();


See also Bug 7722

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 20, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7723


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-03-20 15:28:47 PDT ---
But then that would _force_ you to use UFCS, which would be very bad IMHO. Allowing it is one thing. Forcing it is another thing entirely.

Also, conceptually speaking, filter and map aren't properties at all. They wouldn't make any sense whatsoever as fields on a class or struct. They're definitely functions. And so they shouldn't be marked with @property.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7723



--- Comment #4 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-03-20 18:14:59 PDT ---
It seems to me that you're not looking for a property. You just think that the empty parens are annoying and don't want to have to use them, and property syntax is the only way to do that. Personally, I'm completely against using @property on anything that could conceptually be a field of a class. filter and map are very much functions and are staples of functional languages, so I'm completely against marking them as properties, regardless of what syntactic benefits there may be in doing so.

> Are you sure?
> Even when Bug 7722 will be fixed, I think the following code will be valid:


> @property T head(T)(T[] a) { return a[0]; }
> void main() {
>    int r1 = head([1, 2, 3]);
>    int r2 = [1, 2, 3].head();
>    int r3 = [1, 2, 3].head;
> }

Strong property enforcement would mean that @property functions can _never_ be called with parens, and functions which aren't marked with @property must _always_ be called with parens. That's what TDPL describes. And as such, r3 would be the only legal option. I don't know what the current implementation is doing though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7723



--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-03-20 18:29:13 PDT ---
> This issue is another piece of evidence that -property is a mistake and should never be enforced.

I disagree. It's more an issue of what @property is for. Is it simply to try and enable a syntax where you don't need parens if you don't feel like it, or is it a means of providing functions that act like variables?

Normally, properties are intended as a means of replacing variables with functions that act like the variable but do something more (e.g. enforce invariants). But since D originally took the approach of being lax and letting any function be called without parens if it didn't have any parameters (or be used with = if it only had one), people got used to being lax about the their parens with functions that had nothing to do with properties at all.

And as long as properties are intended to mimic variables rather than simply be a means of being lax with parens, it makes no sense to use @property simply so that you don't need to use parens.

Personally, I suspect that @property is as disputed as it is simply because D took the lax approach initially rather than providing a way to define whether a particular function was a property function or not. If we'd one @property originally or done something like what C# did with get and set, it probably would never have been an issue at all.

Regardless, I'm firmly in the camp of folks in favor of strict enforcement of @property, and I think that this proposal goes against the concept of properties.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7723



--- Comment #7 from Adam D. Ruppe <destructionator@gmail.com> 2012-03-20 18:53:22 PDT ---
(In reply to comment #6)
> I disagree. It's more an issue of what @property is for. Is it simply to try and enable a syntax where you don't need parens if you don't feel like it, or is it a means of providing functions that act like variables?

@property and "property syntax" aren't the same thing, and shouldn't be confused.

D's property syntax is orthogonal to the concept of properties. Yes, it is useful for them, but it also useful for chaining, like seen here, and other things in the wild.

@property is to help functions act like variables, which only relates to syntax when there's ambiguity.


The mistake with -property enforcement is it combines these
two items, while ignoring other uses like function chaining
or property/function hybrids (ones with default arguments,
e.g. if(empty) or if(empty(true)) given bool empty(bool deep = false)).

"Property syntax" should be renamed to "optional parenthesis syntax" to help cure this confusion. Then, it would be clear that -property's enforcement is wrong, and issues like this would resolve themselves.

The legitimate uses work, the ambiguous properties use,
and best of all, it won't break any existing code.

Everybody wins.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7723



--- Comment #11 from bearophile_hugs@eml.cc 2012-03-20 20:53:44 PDT ---
(In reply to comment #10)

> That's definitely wrong. map and filter aren't @properties.

They are, with a different definition of property :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7723


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------