June 11, 2012 Re: Code layout for range-intensive D code | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | I must say that this is what I love about the D community- getting a very thorough answer to a rather basic and newbie question from someone who knows what they're talking about. | |||
June 11, 2012 Re: Code layout for range-intensive D code | ||||
|---|---|---|---|---|
| ||||
On Sunday, June 10, 2012 17:31:37 Jonathan M Davis wrote: > On Monday, June 11, 2012 02:11:24 ixid wrote: > > Thank you. May I ask though, is the argument against automatically appending .array() when a single or chain of lazy functions are used to set a variable or set of variables just syntactic salt against accidentally doing it eagerly? Ouch, I obviously need to do a better job of re-reading my posts. > D doesn't do much of anything like that automatically, Aside from the fact tha foreach supports the ranges, _nothing_ in the compiler supports them. "D doesn't do much of anything like that automatically_._ Aside from the fact _that_ foreach supports ranges, nothing in the compiler supports them." > They're entirely a library artifact. So, the compiler isn't going to do _anything_ to them automatically. And besides, it's not necessarily the case that you want the result of a range-based function to be an array. What if I want to keep the result of map on the stack? > > auto a = map!"to!string(a)"(arr); > > I could pass it to multiple functions later without having to allocate anything. Forcing it to be an array would stop that. And it would be downright nasty for that to happen when dealing with containers, because a number of containers require that you pass them the _exact_ range type that you give them (e.g. remove does this). "a number of containers require that you pass them the exact range type that _they_ give _you_..." > Converting those ranges to arrays > just because you assigned them to a variable would be a _big_ problem. > > And as for infinite ranges again, if they automatically were converted to arrays when assigned to variables, then you couldn't have variables for them at all, because they _have_ to be eager. "because they have to be _lazy_." - Jonathan M Davis | ||||
June 11, 2012 Re: Code layout for range-intensive D code | ||||
|---|---|---|---|---|
| ||||
Posted in reply to ixid | On Mon, Jun 11, 2012 at 2:36 AM, ixid <nuaccount@gmail.com> wrote:
> I must say that this is what I love about the D community- getting a very thorough answer to a rather basic and newbie question from someone who knows what they're talking about.
auto answers = questions.filter!(isBasic)
.filter!(fromNewbie)
.map!(jonathanMDavis)
.array();
Hey, you can even get lazy answers :)
| |||
June 11, 2012 Re: Code layout for range-intensive D code | ||||
|---|---|---|---|---|
| ||||
Posted in reply to ixid | ixid: > Having to append .array() all the time is rather annoying. I can't help but feel that there's a better solution than this. Are lazy Result methods really the default way of doing things? I'd rather have eager versions. In most cases having a lazy range is the right default. On the other hand in D many times you can't use lazy ranges, you need arrays, so the ".array()" is quite common after a map or filter. So I propose to add to Phobos two small functions named amap/afilter that produce arrays: http://d.puremagic.com/issues/show_bug.cgi?id=5756 If you think those are redundant, then first of all take a look here: http://d.puremagic.com/issues/show_bug.cgi?id=8155 Bye, bearophile | |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply