www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7723] New: property filter/filter

reply d-bugmail puremagic.com writes:
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



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: -------
Mar 18 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7723


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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: -------
Mar 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7723




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: -------
Mar 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7723




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 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: -------
Mar 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7723




18:53:22 PDT ---

 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: -------
Mar 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7723






 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: -------
Mar 20 2012
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 20 2012