On 2013-02-27 18:35, H. S. Teoh wrote:
Not sure who you're referring to here, but the reason reduce probably
will not change is because a lot of code relies on the current order of
parameters, and deliberately breaking that just for aesthetic (rather
than functional) reasons is not a good idea. It would be a different
story if the current order of parameters somehow makes it impossible to
implement some particular functionality. I agree that perhaps the
current situation is not perfect, but at least it's not a complete road
blocker.
That's the problem. Then we will have a language with a slightly
inconsistent and inconvenient standard library.
Isn't that the same as:
map!((obj x) { doSomething(x); return x; })(range)
?
I know it's not as pretty, but at least it's possible.
No it's not the same thing. "map" expects a range and returns a new
range. "map" will pass each element from the range to the delegate and
then return a new range of all elements returned for each call to the
delegate.
"tap" on the other hand expects an object or value. It will then pass
the object to the delegate and then return the object. Note that it
doesn't return whats returned from the delegate. It will always return
the object passed to "tap".
The most basic, non-templated implementation of "tap" would look like this:
Object tap (alias func) (Object o)
{
func(o);
return o;
}
class Point
{
int x;
int y;
}
Point createPoint ()
{
return (new Point).tap!((p) { p.x = 3; p.y = 4 });
}
Again, my point was not that it's a bad idea to have isBlank. My point
was that if you add isBlank, then isPresent is redundant, and I would
argue even harmful. The best APIs are minimal ones, that provide all
*necessary* primitives with minimal overlap between them.
OK, then it was a misunderstanding, my bad. But with this philosophy it
will not be as easy create quick scripts compared to scripting
languages. This the original question, how to improve that in D.
--
/Jacob Carlborg
