On Tue, Aug 7, 2012 at 12:27 PM, Timon Gehr <timon.g...@gmx.ch> wrote: > On 08/07/2012 08:37 PM, José Armando García Sancio wrote: >> >> 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). > > > It is also a matter of execution speed and GC pressure. None of the D > compilers is able to inline delegate parameters at least as well as > alias template parameters afaik. > > Furthermore, only the current form can _guarantee_ that no hidden GC > allocations take place due to parameter passing to map. >
Interesting. I can't speak for the GC and allocation you mention since I never tried to implement this myself but I should point out that C++ STL's algorithm "module" (transform, for_each, etc) works this way. Having said that, if D can't infer the type of lambda parameters (which I thought the current version of D could) and create a function/delegate based on the body then this is a no go. Thanks for you insight. -Jose