On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr <timon.g...@gmx.ch> wrote: > On 08/07/2012 07:59 AM, José Armando García Sancio wrote: >> >> On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+s...@gmail.com> wrote: >>> >>> On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote: >>>> >>>> >>>> On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote: >>>>> >>>>> >>>>> I'd be very surprised if all that many people compile with -property. >>>> >>>> >>>> >>>> Indeed. Sometimes I try it just to see what happens, and always the same >>>> results: it doesn't solve problems and complains about code. >>>> >>>> Some examples of things that break: >>>> >>>> import std.algorithm; >>>> foreach(i; [1,2,3].map!"a+1") { >>>> >>>> } >>>> prophate.d(5): Error: not a property [1,2,3].map!("a+1") >>>> >>>> >>>> Of course, this is relatively new, using ufcs in 2.059, so the breakage >>>> probably isn't too bad, but I'm not the only one who writes it this way >>>> - >>>> I've seen a number of reddit and newsgroup comments do this too, >>>> especially >>>> when chaining it. >>>> [snip] >>> >>> >>> >>> I completely agree, particularl with the UFCS part. UFCS is designed to >>> get >>> rid of the horrible mess of (), and now we want to arbitrarily force a () >>> anyways? Seems like it defeats the purpose. To me, when comparing >>> range.filter!"a> 2".map!"a*a".countUntil(3) >>> to >>> range.filter!"a> 2"().map!"a*a"().countUntil(3) >>> Those extra paranthesis just don't do anything, they don't give extra >>> meaning, they don't accomplish anything useful but distract from the >>> actual >>> expression. >>> >> >> Just a small comment. I have been following this thread a little and >> was somewhat surprise that the argument against enforcing parenthesis >> on non-properties is that a call like [1,2,3].map!"a+1" would look >> ugly as [1,2,3].map!"a+1"(). To me that is a issue of the >> std.algorithm module and not so much of the language. >> >> >> Personally I am not a huge fan of using strings as a way to pass a >> function into a high-order function. I suspect that this string stuff >> became popular because D didn't have lambda declarations and type >> inference when the module was designed and implemented. > > > String lambdas would quite certainly have been left out. > Anyway, string lambdas are unrelated to the discussion of std.algorithm > idioms in this context. > > [1,2,3].map!(a=>a+1) > > [1,2,3].map!(a=>a+1)()
Yep. The "problem" is not string lambda but that the mapping function is passed a template argument (which you need for string lambda to work). I guess that this is nice because you can alias the template or pass multiple lambdas (a little obscure but okay). If the lambda function was passed as a runtime parameter and not a template parameter can just do: [1, 2, 3].map(a=>a+1) If this was the case we wouldn't be talking about this non-property vs property with regard to map. I other words the map signature could look as follow (pseudo-code): Range!T map(T, U)(Range!U range, T delegate(U)); Thanks, -Jose P.S. You can still alias the map using a closure that binds the delegate but I digress.