Lutger:
>I was referring to your suggestion of adding features to see how they pan out
>and then removing them, not any particular feature.<
Yes, there's a small contradiction there, because usually there's no a single
best solution to a problem, and even oppostite strategies may be both useful in
different situations.
But I was mostly talking about finding a way to play very well with an
experimental feature before adding it to the real language.
>list comprehensions don't do anything useful over map & friends but make them
>look better.<
I don't agree because:
- They are indeed syntax sugar, but they allow for shorter, less
noisy/cluttered, and more readable code (IF and only if their syntax is really
good), this improves code, makes it more readable, avoids errors, etc.
- You often don't need delegates, so:
(x * x for x in xrange(10, 20) if x & 1)
doesn't require the compiler to be able to inline two closures as in:
xfilter((int x){ return x & 1; }, xmap((int x){ return x * x; }, xrange(10,
20)))
(This is code from my dlibs, and it's not much readable. "xsomething" means
it's lazy, as in that Python line of code. Phobos2 usually doesn't need
delegates here. Currently DMD and LDC aren't able to inline closures it seems
no one is interested in this and I don't know why).
>They are super handsome in python in combination with tuples.<
Tuples are very handy, and I'd like to have a good support for them in D. But
note that there are no tuples in that code I have just shown.
Bye,
bearophile
