"Marc Gravell" <ma**********@gmail.comwrote in message
news:f2**********************************@y38g2000 hsy.googlegroups.com...
>To be honest, all we really need is a let-expression that could be used
to
introduce variables within the scope of a (sub)expression.
Well, I'm not sure the "introduce variables" gives us anything we
don't already have
It does, because it blurs the separation between statements and expressions
further, and allows you to do some things inline which right now have to be
split into several statements (and therefore cannot be done in the middle of
a LINQ query, for example, and has to be refactored into a method of its
own).
It's actually rather telling that LINQ itself has "let" - obviously there
are many scenarios where it's vital. Unfortunately, there are just as many
scenarios which don't involve LINQ, but which could use "let" for the same
reasons.
Re the Bind - this is unnecessary; you can do the same just with an
inline ternary (or a static method, which would remove the need for
delegate invoke):
You can do it if you already have the value of an expression bound to a
variable. The point of Bind is to take an expression, evaluate it once, bind
it to a name, and reuse that name inside some other expression several times
without the original expression being re-evaluated every time. In essence,
Bind is the precise equivalent of "let".
(here I've added the missing brackets to show the worst-case of what
it would need to support)
static int MyFunc(int x)
{
return (x >= 80) ? (80)
: ((x >= 60) ? (60)
: ((x >= 40) ? (40)
: ((x >= 20) ? (20)
: (0))));
}
Declaring a separate method for every such conditional (or indeed, any
expression that needs to reuse the value of some other expression) is very
inconvenient. That's why we have lambdas, after all...