@property

[José Armando García Sancio]

On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr <timon.gehr at 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+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.
>
>
> 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.