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
oth
On Mon, Jun 11, 2012 at 2:36 AM, ixid 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)
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
>
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.
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?
D doesn't d
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?
On Sunday, June 10, 2012 23:49:12 ixid wrote:
> 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.
Eager versions are only g
On Sunday, 10 June 2012 at 21:49:14 UTC, ixid wrote:
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.
Problem with eager ve
On 11.06.2012 1:49, ixid wrote:
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.
And then try to get lazy version back. Now
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.
On 09.06.2012 14:43, bearophile wrote:
[snip]
import std.stdio, std.algorithm, std.string, std.range, std.conv;
void main() {
auto t = "table.txt"
.File()
.byLine()
.map!(r => r.removechars("^01".dup))()
.array();
const transposed = t[0]
.length
.iota()
//hopefully I'm not alone in that this
"bearophile" wrote in message
news:lkplokawtyisvwhvf...@forum.dlang.org...
> The introduction of UFCS in D offers new ways to format D code, especially
> when your code uses many high order functions. What is a good layout of
> the D code in such situations? I have tried several alternative lay
09.06.2012 14:43, bearophile пишет:
The introduction of UFCS in D offers new ways to format D code,
especially when your code uses many high order functions.
I have to mention that one shouldn't write range-intensive D code for
now. It's too risky to use high level functions in D because it ca
The introduction of UFCS in D offers new ways to format D code,
especially when your code uses many high order functions. What is
a good layout of the D code in such situations? I have tried
several alternative layouts, and in the end I found to appreciate
a layout similar to the one used in F#
14 matches
Mail list logo
