Future of string lambda functions/string predicate functions

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Aug 15 08:03:57 PDT 2013


On Thu, Aug 15, 2013 at 07:13:18AM +0200, deadalnix wrote:
> On Thursday, 15 August 2013 at 02:30:50 UTC, Jonathan M Davis wrote:
> >On Wednesday, August 14, 2013 09:26:20 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.
> >
> >I'd simply argue for doing something like binaryOp!"<" and
> >unaryOp!"-".  Creating different names for all of the various
> >operators is not at all in line with how do things normally and
> >definitely seems unattractive. In contrast, by creating specific
> >templates for operators, we cover the main use cases where the string
> >lambdas are more attractive than the newer lambda literals. It's also
> >in line with how do operator overloading.

That's a good idea:

	unaryOp!"-"		// -a
	binaryOp!"-"		// a-b
	binaryOp!("-", 5)	// a-5
	binaryOp!"<"		// a<b
	binaryOp!("<", 5)	// a<5


[...]
> Yes and avoid stupid template duplication like with "a>b" "a > b" or
> by not having equals delegate literals.

+1


> This is clearly the best option for simple operations. Complex
> operation should be migrated to delegate literals.

+1.


T

-- 
"Hi." "'Lo."


More information about the Digitalmars-d mailing list