@property

[Timon Gehr]

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.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).

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.

> 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)
>

Well, no you cannot, because the current language would not be able to
deduce a type for 'a'.

> If this was the case we wouldn't be talking about this non-property vs
> property with regard to map.

We would be talking about improving IFTI to support cross-parameter
type deduction. (and maybe we would constantly be complaining about
poor GC performance.) Some programmers who use it now would presumably
avoid std.algorithm because of the poor predictability of performance.