On 10-Jul-12 17:56, Jacob Carlborg wrote:
On 2012-07-10 15:28, Andrei Alexandrescu wrote:
We can arrange things in the library that a custom message is issued, or
in the compiler to do it once for all. At any rate whenever there's an
error pointing somewhere in the library's code that's an insufficient
template constraint that should be fixed.
I mean, is it possible to have the original code work?
auto bar = foo.chain("bar");
Or perhaps more appropriate:
auto bar = foo.append("bar");
Well I made minimal changes. Besides I don't know what the intent is.
Have a look at this:
https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L217
I'm not sure how map can fit there. If anything you need a foreach (and
you have it;) ) to build a _string_. I'd rather output ',' right there
inside of loop. Thus avoiding costly join and appending to a new buffer
on each iteration.
Other then doing it with Appender and generalizing to any OutputRange I
fail to see a problem.
I was going to replace the foreach-loop in the above code with a call to
"map". But "map" returns a range, not an array. Therefor the append at
line 245 won't work. How would I do line 245 if "params" is a range
returned by "map"?
It seems unnecessary to have to convert the range to an array before
"join" is called on line 247.
Indeed I agree there should be no error in library code. What I meant to
say was, when I saw the code I thought "I bet this is an lvalue thing",
and then when I saw lvalue in the error I was satisfied.
Jonathan has already reported these two bugs.
I understand. So you need to use array() to convert the lazy map result
into an eager array. I disagree this is unintuitive, if it were then
very little of D would make sense are lazy, non-array ranges are
everywhere.
Tell me what is the point of std.algorithm and ranges if I have to
convert every single result of an algorithm to an array before I can use
it with an other algorithm? I thought the whole idea was to avoid
allocations between different usages of algorithms.
Speed and generality. Think removing temporary arrays. And while a lot
of folks won't every use things other then arrays power users sure as
hell would.
--
Dmitry Olshansky
