Future of string lambda functions/string predicate functions
John Colvin
john.loughran.colvin at gmail.com
Wed Aug 14 10:03:32 PDT 2013
On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote:
> On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu
> wrote:
>> On 8/14/13 7:34 AM, H. S. Teoh wrote:
> [...]
>> >That's a bit too terse. What about this:
>> >
>> > less // a < b
>> > less!(5) // a < 5
>> > lessEq // a <= b
>> > lessEq!(5) // a <= 5
>> > more // a > b
>> > more!(5) // a > 5
>> > moreEq // a >= b
>> > moreEq!(5) // a >= 5
>> > equal // a == b
>> > equal!(5) // a == 5
>> > notEqual // a != b
>> > notEqual!(5) // a != 5
>>
>> At this point using "a < b" for a < b, "a < 5" for a < 5 etc.
>> becomes awfully attractive.
> [...]
>
> It just occurred to me, that perhaps what we really need here
> is an
> even more abbreviated form of lambda literals, like this:
>
> sort!(a < b)(range);
>
> where 'a' and 'b' are undefined identifiers in the current
> scope, and
> the compiler would know to bind them to lambda parameters.
> Defined
> identifiers would, naturally, bind to whatever they refer to:
>
> int x = 5;
> find!(a == x)(range);
>
> This would be equivalent to:
>
> int x = 5;
> find!((a) => a==x)(range);
>
> IOW, an expression that references undefined identifiers in a
> template
> parameter would be turned into a lambda that parametrize said
> identifiers.
>
>
> T
That's a bit too fragile IMO.
int b; //rename to 'a'
// lots of intermediate code...
int x = 5;
r.blah!(a == x);
Renaming of a seemingly unrelated variable would result in spooky
action-at-a-distance behaviour.
More information about the Digitalmars-d
mailing list