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