On Mon, Aug 6, 2012 at 11:31 PM, Brad Anderson <e...@gnuk.net> wrote: > On Mon, Aug 6, 2012 at 11:59 PM, José Armando García Sancio > <jsan...@gmail.com> 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. I wonder if >> the module signatures would look different if you designed it to use >> the current features of D. >> >> To be honest, when first saw 'some_array.map!"a+1"()' a few years back >> when I first learned about D my knee jerk reaction was: "from where in >> the world is 'a' coming from?". I remember I had to read >> std/algorithm.d and whatever module implements unary "string" >> functions to figure out what was going on. Anyways, I digress. >> >> Part of me looks forward to the day that I can use D reliably another >> part of my wants to just wait for Rust to hopefully get it "right". >> >> Thanks, >> -Jose > > > There was a pull to switch std.algorithm over to the new lambda syntax (by > me). It caused the dmd unit tests to fail though. There is also an issue > with intermodule visibility of nested structs that popped up and prevented > the every function from being switched over. I should probably recreate the > pull request so one of the compiler guys can take a look. > > BA
Wow. That would be nice! I would like to see such a change though I assume that such a change would break a lot of code. No?