@property

[José Armando García Sancio]

On Mon, Aug 6, 2012 at 11:31 PM, Brad Anderson <eco at gnuk.net> wrote:
> On Mon, Aug 6, 2012 at 11:59 PM, José Armando García Sancio
> <jsancio at gmail.com> wrote:
>>
>> On Sun, Aug 5, 2012 at 2:32 PM, Kapps <opantm2+spam at 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?