On Tuesday, 15 September 2015 at 14:19:13 UTC, Daniel Kozák wrote:
Which OS?
It's CentOS release 6.5 (Final), I tried dmd 2.068.1 and the
problem has disappeared. Thanks very much for the advice, I can
stick to old gdc for speed until ldc catches up to 2.068.
Best
Andrew
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an
On Tuesday, 18 August 2015 at 16:02:42 UTC, cym13 wrote:
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be
On Tuesday, 18 August 2015 at 17:44:00 UTC, Xinok wrote:
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be
On Tuesday, 18 August 2015 at 16:51:01 UTC, ixid wrote:
On Tuesday, 18 August 2015 at 16:02:42 UTC, cym13 wrote:
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an
On Thursday, 11 June 2015 at 08:24:25 UTC, Dmitry Olshansky wrote:
On 11-Jun-2015 11:18, w0rp wrote:
A thought just came to me. When I'm implementing foreach for a
container, I'm left with the choice of using a range for a
container or
opApply. I've found often that I prefer the ranges, as
On 6/11/15 4:24 AM, Dmitry Olshansky wrote:
Already works. Just define opSlice for container that returns a range
and then:
foreach(elem; container) {}
is lowered to:
foreach(elem; container[]) {}
I think you want to do opIndex which takes no parameters. opSlice is no
longer supposed to
On 6/11/15 8:54 AM, Dmitry Olshansky wrote:
On 11-Jun-2015 15:22, Steven Schveighoffer wrote:
On 6/11/15 4:24 AM, Dmitry Olshansky wrote:
Already works. Just define opSlice for container that returns a range
and then:
foreach(elem; container) {}
is lowered to:
foreach(elem; container[]) {}
On 11-Jun-2015 15:22, Steven Schveighoffer wrote:
On 6/11/15 4:24 AM, Dmitry Olshansky wrote:
Already works. Just define opSlice for container that returns a range
and then:
foreach(elem; container) {}
is lowered to:
foreach(elem; container[]) {}
I think you want to do opIndex which
On Thursday, 11 June 2015 at 08:24:25 UTC, Dmitry Olshansky wrote:
On 11-Jun-2015 11:18, w0rp wrote:
A thought just came to me. When I'm implementing foreach for a
container, I'm left with the choice of using a range for a
container or
opApply. I've found often that I prefer the ranges, as
On Thursday, 11 June 2015 at 13:09:21 UTC, Steven Schveighoffer
wrote:
On 6/11/15 8:54 AM, Dmitry Olshansky wrote:
On 11-Jun-2015 15:22, Steven Schveighoffer wrote:
On 6/11/15 4:24 AM, Dmitry Olshansky wrote:
Already works. Just define opSlice for container that
returns a range
and then:
On 6/11/15 4:31 PM, Jonathan M Davis wrote:
On Thursday, 11 June 2015 at 13:09:21 UTC, Steven Schveighoffer wrote:
On 6/11/15 8:54 AM, Dmitry Olshansky wrote:
On 11-Jun-2015 15:22, Steven Schveighoffer wrote:
On 6/11/15 4:24 AM, Dmitry Olshansky wrote:
Already works. Just define opSlice for
On 6/11/15 5:06 PM, Jonathan M Davis wrote:
On Thursday, 11 June 2015 at 20:54:46 UTC, Steven Schveighoffer wrote:
It makes sense, and is very extendable, and uniform. You can deal with
this much easier when imlplementing some sort of wrapping than one
that has to do something different
On Thursday, 11 June 2015 at 20:54:46 UTC, Steven Schveighoffer
wrote:
It makes sense, and is very extendable, and uniform. You can
deal with this much easier when imlplementing some sort of
wrapping than one that has to do something different depending
on how many args are passed inside the
On 11-Jun-2015 11:18, w0rp wrote:
A thought just came to me. When I'm implementing foreach for a
container, I'm left with the choice of using a range for a container or
opApply. I've found often that I prefer the ranges, as it's easy for me
to write a range that satisfies @nogc @safe pure
I found a solution I like a lot, with templated opApply:
class Cont{
Thing[] kids;
int opApply(T)(int delegate(ref T) dg){
int result = 0;
for (int i = 0; i kids.length; i++){
T t = cast(T)kids[i];
Thank you Adam, Bbaz and Ola for the helpful thoughts. I dumped
them in a wiki page off the sandbox but needs editing and
refining.
On Friday, 30 January 2015 at 14:41:11 UTC, Laeeth Isharc wrote:
Thanks, Adam. That's what I had thought (your first
paragraph), but something Ola on a different thread confused me
and made me think I didn't understand it, and I wanted to pin
it down.
There is always significant
On Friday, 30 January 2015 at 12:55:20 UTC, Adam D. Ruppe wrote:
On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote:
As I understand it, foreach allocates when a simple C-style
for using an array index would not.
foreach is just syntax sugar over a for loop. If there's any
On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote:
Hi.
The standard advice is not to worry about memory usage and
execution speed until profiling shows you where the problem is,
and I respect Knuth greatly as a thinker.
Still, one may learn from others' experience and
On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote:
As I understand it, foreach allocates when a simple C-style for
using an array index would not.
foreach is just syntax sugar over a for loop. If there's any
allocations, it is because your code had some, it isn't inherit
to the
On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote:
Hi.
The standard advice is not to worry about memory usage and
execution speed until profiling shows you where the problem is,
and I respect Knuth greatly as a thinker.
Still, one may learn from others' experience and
On Sunday, 11 January 2015 at 23:50:18 UTC, Ali Çehreli wrote:
On 01/11/2015 12:25 PM, Zaher Dirkey wrote:
reproduce example here
http://dpaste.dzfl.pl/13fb453d0b1e
That link doesn't work for me. (?)
Does opApply return the delegate's return value ('b' below)?
import std.stdio;
struct S
{
On 01/11/2015 12:25 PM, Zaher Dirkey wrote:
reproduce example here
http://dpaste.dzfl.pl/13fb453d0b1e
That link doesn't work for me. (?)
Does opApply return the delegate's return value ('b' below)?
import std.stdio;
struct S
{
int opApply(int delegate(int) dg)
{
foreach (i;
On Sunday, 11 January 2015 at 23:50:18 UTC, Ali Çehreli wrote:
On 01/11/2015 12:25 PM, Zaher Dirkey wrote:
reproduce example here
http://dpaste.dzfl.pl/13fb453d0b1e
That link doesn't work for me. (?)
Does opApply return the delegate's return value ('b' below)?
It must return object, but
On Sun, 24 Aug 2014 13:22:49 +
Stefan Frijters via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
@nogc is a part of signature. gc-function can't call @nogc-one. the
same is with calling @system function from @safe one, for example. or
impure function from pure.
so to say,
ketmar:
there is currenly no way to specify attributes for such implicit
delegates.
It could be a nice language enhancement.
Bye,
bearophile
On Sun, 24 Aug 2014 13:58:45 +
bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
there is currenly no way to specify attributes for such implicit
delegates.
It could be a nice language enhancement.
i agree. but i tend not to fill enhancement requests without
On Sun, 24 Aug 2014 14:34:02 +
bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
putting this information in Bugzilla is better than letting this
get forgotten.
so it can be forgotten in Bugzilla. ;-)
signature.asc
Description: PGP signature
On Sun, Aug 24, 2014 at 05:49:29PM +0300, ketmar via Digitalmars-d-learn wrote:
On Sun, 24 Aug 2014 14:34:02 +
bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
putting this information in Bugzilla is better than letting this
get forgotten.
so it can be
ketmar:
so it can be forgotten in Bugzilla. ;-)
And in ten, or one hundred or one thousand years the whole D
language will be forgotten. There are various levels of
remembering and forgetting. Putting bugs and ERs in databases is
a different kind of forgetting.
Bye,
bearophile
On Sun, 24 Aug 2014 08:02:40 -0700
H. S. Teoh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Some of us regularly comb through old bugzilla issues to find things
to test fix. It may take a long time, but we do try. :-)
(And we could use a lot of help -- there are only a
On Sunday, 24 August 2014 at 14:34:03 UTC, bearophile wrote:
ketmar:
but i tend not to fill enhancement requests without
corresponding patches,
I agree that having a patch ready is much better. But people
like me file hundreds of ERs without too much damage done, and
many of them get
On 08/24/2014 06:40 AM, ketmar via Digitalmars-d-learn wrote:
On Sun, 24 Aug 2014 13:22:49 +
Stefan Frijters via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
@nogc is a part of signature. gc-function can't call @nogc-one. the
same is with calling @system function from
On Sun, 24 Aug 2014 11:45:14 -0700
Ali Çehreli via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Yeah, the only reason why the original code does not work is the
write() expression in the foreach body.
hm. really. i forgot what is delegate body for opApply. sure, here we
can't
On Sunday, 24 August 2014 at 18:55:09 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sun, 24 Aug 2014 11:45:14 -0700
Ali Çehreli via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
Yeah, the only reason why the original code does not work is
the
write() expression in the foreach
On Sun, 24 Aug 2014 19:23:01 +
Stefan Frijters via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
request I do have a followup question: is it possible somehow to
have both a @nogc and a normal opApply function available?
you can use templated opApply():
import std.traits;
On 08/11/2014 08:40 AM, Jonathan Marler wrote:
I know this is kinda nit picky but it would be nice if foreach
supported iterating through input ranges without accessing the front
function.
foreach(myInputRange) {
// myInputRange has a front function but it is
// never called
On 08/14/2014 07:39 PM, Ali Çehreli wrote:
On 08/11/2014 08:40 AM, Jonathan Marler wrote:
I know this is kinda nit picky but it would be nice if foreach
supported iterating through input ranges without accessing the front
function.
foreach(myInputRange) {
// myInputRange has a
On Thu, Aug 14, 2014 at 10:39:48AM -0700, Ali Çehreli via Digitalmars-d wrote:
[...]
The syntax does not allow that but I have discovered a WAT! :) If you
implement iteration by opApply() member functions, it is possible to
use any random name and it works.
The following type provides both
On 08/14/2014 11:16 AM, Timon Gehr wrote:
On 08/14/2014 07:39 PM, Ali Çehreli wrote:
On 08/11/2014 08:40 AM, Jonathan Marler wrote:
I know this is kinda nit picky but it would be nice if foreach
supported iterating through input ranges without accessing the front
function.
On Monday, 11 August 2014 at 15:40:18 UTC, Jonathan Marler wrote:
I know this is kinda nit picky but it would be nice if
foreach supported iterating through input ranges without
accessing the front function.
foreach(myInputRange) {
// myInputRange has a front function but it is
//
`foreach` should manage it's own iterator's resources - it
shouldn't rely on some memory declared outside it's scope
that'll be accessible after the loop is finished. You can
You say `foreach` should manage it's own iterator's resources but
why? The std.stdio function byChunk allows you to
On Monday, 16 June 2014 at 21:47:22 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Mon, Jun 16, 2014 at 01:31:21PM -0700, H. S. Teoh via
Digitalmars-d wrote:
On Mon, Jun 16, 2014 at 06:37:56PM +, Wyatt via
Digitalmars-d wrote:
On Monday, 16 June 2014 at 17:52:29 UTC, H. S. Teoh via
On 17/06/2014 7:59 p.m., monarch_dodra wrote:
On Monday, 16 June 2014 at 21:47:22 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Mon, Jun 16, 2014 at 01:31:21PM -0700, H. S. Teoh via Digitalmars-d
wrote:
On Mon, Jun 16, 2014 at 06:37:56PM +, Wyatt via Digitalmars-d wrote:
On Monday, 16 June
On Monday, 16 June 2014 at 20:32:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
Another recent enterprise nastiness I ran into: having
several functions with identical name in the source tree, each
of which does something completely different, and which one
ends up in the executable depends on
On Tue, Jun 17, 2014 at 07:59:22AM +, monarch_dodra via Digitalmars-d wrote:
[...]
We recently did some cleanup in our organization in regards to a
couple functions whose argument counts were are too damn high: We
created a helper-class which actually contains the arguments. So the
calls
On Sun, 15 Jun 2014 20:38:53 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sun, Jun 15, 2014 at 03:05:37AM -0400, Nick Sabalausky via
Digitalmars-d wrote:
[...]
True story: I once had to put up with a production codebase (the
company's *flagship* product) that
On Mon, Jun 16, 2014 at 09:24:56AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On Sun, 15 Jun 2014 20:38:53 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sun, Jun 15, 2014 at 03:05:37AM -0400, Nick Sabalausky via
Digitalmars-d wrote:
[...]
True story:
On Mon, 16 Jun 2014 10:53:49 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Mon, Jun 16, 2014 at 09:24:56AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On Sun, 15 Jun 2014 20:38:53 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On
On 6/16/2014 11:09 AM, Steven Schveighoffer wrote:
On Mon, 16 Jun 2014 10:53:49 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Mon, Jun 16, 2014 at 09:24:56AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On Sun, 15 Jun 2014 20:38:53 -0400, H. S. Teoh via
On Mon, Jun 16, 2014 at 01:30:02PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
Yes. I can understand the whole goto error thing in a VB codebase
since, just like HS Teoh's C example, it's often the only clean-ish
way to handle errors in VB (Talking pre-.NET here, of course). The
On 6/16/2014 1:50 PM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Jun 16, 2014 at 01:30:02PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
Yes. I can understand the whole goto error thing in a VB codebase
since, just like HS Teoh's C example, it's often the only clean-ish
way to handle
On Monday, 16 June 2014 at 17:52:29 UTC, H. S. Teoh via
Digitalmars-d wrote:
I have seen 600+-line (and bigger) functions in enterprise
production code. I don't recall seeing using goto's in such
functions for flow control (other than error handling), but I
may have missed them. :-P
Legacy
On Mon, 16 Jun 2014 14:36:29 -0400, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
On 6/16/2014 1:50 PM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Jun 16, 2014 at 01:30:02PM -0400, Nick Sabalausky via
Digitalmars-d wrote:
[...]
Yes. I can understand the whole goto error
On 6/16/2014 2:48 PM, Steven Schveighoffer wrote:
On Mon, 16 Jun 2014 14:36:29 -0400, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
output(50) = junk junk
output(52) = junkedy junk
output(8) = blort
print join(output)
Note the sensible and orderly numbering scheme.
The whole
On Mon, Jun 16, 2014 at 06:37:56PM +, Wyatt via Digitalmars-d wrote:
On Monday, 16 June 2014 at 17:52:29 UTC, H. S. Teoh via Digitalmars-d wrote:
[...]
Or, on the flip side, functions with 10-15 parameters, each of which
influences which subset of the others actually have any effect.
On Mon, Jun 16, 2014 at 01:31:21PM -0700, H. S. Teoh via Digitalmars-d wrote:
On Mon, Jun 16, 2014 at 06:37:56PM +, Wyatt via Digitalmars-d wrote:
On Monday, 16 June 2014 at 17:52:29 UTC, H. S. Teoh via Digitalmars-d wrote:
[...]
Or, on the flip side, functions with 10-15 parameters,
On 6/13/2014 10:03 AM, H. S. Teoh via Digitalmars-d wrote:
FWIW, I also see `for(;;)` as far better than `while(true)`. I like to
read `(;;)` as ever, so it literally reads forever { ... }. :-) (In
fact, in C/C++, you *could* #define ever (;;), then you can actually
write for ever.
On 6/15/2014 2:21 AM, Walter Bright wrote:
On 6/13/2014 10:03 AM, H. S. Teoh via Digitalmars-d wrote:
FWIW, I also see `for(;;)` as far better than `while(true)`. I like to
read `(;;)` as ever, so it literally reads forever { ... }. :-) (In
fact, in C/C++, you *could* #define ever (;;), then
On Sunday, 15 June 2014 at 07:05:37 UTC, Nick Sabalausky wrote:
True story: I once had to put up with a production codebase
(the company's *flagship* product) that wasn't asm (it was VB6)
and yet was filled with garbage like this:
if ...cond... then
...statements...
goto somelabel
end
On Sun, Jun 15, 2014 at 03:05:37AM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
True story: I once had to put up with a production codebase (the
company's *flagship* product) that wasn't asm (it was VB6) and yet was
filled with garbage like this:
if ...cond... then
On 2014-06-13 20:03, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jun 13, 2014 at 10:46:17AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
for(;;) is a special case with no real benefit IMHO. It's a loop whose
condition is implicitly true rather than actually having a condition
in it.
On Friday, 13 June 2014 at 21:41:43 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Fri, 13 Jun 2014 11:03:14 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I disagree, it's not a special case. It's simply a logical
consequence
of each part of the for-loop being
On 12/06/2014 18:30, Nick Treleaven wrote:
On 12/06/2014 17:59, bearophile wrote:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Perhaps with something other than a range then. There are some uses in
Phobos:
On 06/13/2014 11:41 PM, Jonathan M Davis via Digitalmars-d wrote:
It's a special case in that the middle portion is supposed to be the condition
that the loop use to determine whether it can continue, and omitting it means
that it has to add the true itself,
No, omitting it means that it does
Timon Gehr:
Have you ever used void[0][T]?
I have never used that so far. What is it useful for?
Bye,
bearophile
The idea of using code like this (only one or the other should be
allowed) is rather natural, it breaks nothing, it avoids the
programmer to introduce a variable that is not needed, making the
code less noisy:
foreach (;0 .. 10) {...}
foreach (0 .. 10) {...}
I don't see the need for so many
On 06/14/2014 05:33 PM, bearophile wrote:
Timon Gehr:
Have you ever used void[0][T]?
I have never used that so far. What is it useful for?
Bye,
bearophile
It's a hash set with a somewhat awkward interface.
On Sat, 14 Jun 2014 10:20:51 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 13 June 2014 at 21:41:43 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Fri, 13 Jun 2014 11:03:14 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I disagree, it's
On 06/14/2014 11:23 PM, Jonathan M Davis via Digitalmars-d wrote:
...
It's the lack of a condition that I object to. IMHO it's a fundamental
violation of how loops work.
Fundamentally, loops loop. That is the only fundamental thing about loops.
On Sat, Jun 14, 2014 at 02:23:36PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
On Sat, 14 Jun 2014 10:20:51 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
[...]
But this special treatment of the second operand is the same in all
forms of the for loop:
for(int i =
On 6/14/2014 9:15 AM, Timon Gehr wrote:
On 06/13/2014 11:41 PM, Jonathan M Davis via Digitalmars-d wrote:
It's a special case in that the middle portion is supposed to be the
condition
that the loop use to determine whether it can continue, and omitting
it means
that it has to add the true
On 12/06/14 21:21, Nick Sabalausky wrote:
- I rarely need to do that. Most of my N times loops exist *because* I
want to use the index.
I use the n.times in Ruby for testing quite a lot. When I need to
create x instances of a class and it doesn't matter what values they
have. Although I
On 12/06/14 17:00, Manu via Digitalmars-d wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
If 'for' lets you
On Fri, 13 Jun 2014 01:00:11 +1000
Manu via Digitalmars-d digitalmars-d@puremagic.com wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You
On Thursday, 12 June 2014 at 16:59:34 UTC, bearophile wrote:
Nick Treleaven:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used
it so far.
Would enforcing immutability there be a breaking change?
foreach (/*immutable*/
On Thursday, 12 June 2014 at 22:38:26 UTC, Daniel Kozák via
Digitalmars-d wrote:
No problem for me:
http://stackoverflow.com/questions/23950796/how-to-repeat-a-statement-n-times-simple-loop/23952012#23952012
Would be nice if we could elide the parentheses and semicolons:
10.times! {
On Friday, 13 June 2014 at 09:29:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(;
0..n) {} added.
I don't like special cases like like these.
And I really don't think that it's a big deal to have to
provide a counter
variable
On 13/06/14 11:28, Marc Schütz schue...@gmx.net wrote:
Would be nice if we could elide the parentheses and semicolons:
10.times! {
writeln(Do It!);
}
10.times! (uint n) {
writeln(n + 1, Round);
}
Yeah, that has been suggested before.
--
/Jacob Carlborg
On Thursday, 12 June 2014 at 15:00:20 UTC, Manu via Digitalmars-d
wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
On 13/06/2014 3:00 a.m., Manu via Digitalmars-d wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
If 'for' lets
On 13 June 2014 19:15, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Fri, 13 Jun 2014 01:00:11 +1000
Manu via Digitalmars-d digitalmars-d@puremagic.com wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do
On 06/12/2014 06:59 PM, bearophile wrote:
Nick Treleaven:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Have you ever used void[0][T]?
On 6/12/14, 9:41 PM, Nick Sabalausky wrote:
On 6/12/2014 8:36 PM, Ary Borenszweig wrote:
You normally do that by using names that the grammar doesn't allow as
valid identifiers. Then you have a counter and prepend that. This way
you never have name collisions.
And doesn't DMD *already* do a
On Friday, 13 June 2014 at 09:29:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(;
0..n) {} added.
Just out of curiosity, what is it you don't like about for(;;).
For what it's worth, I like using for(;;) a lot, because quite
On 12/06/2014 16:57, simendsjo wrote:
Does any sane person use _ as a variable identifier and
then reference it?
I forgot that C gettext has a macro called _(), and this D version also
has it (which is available via dub):
https://github.com/NCrashed/dtext/blob/master/source/dtext.d#L115
On Friday, 13 June 2014 at 15:18:52 UTC, Nick Treleaven wrote:
On 12/06/2014 16:57, simendsjo wrote:
Does any sane person use _ as a variable identifier and
then reference it?
I forgot that C gettext has a macro called _(), and this D
version also has it (which is available via dub):
On 06/13/2014 01:55 PM, Dicebot wrote:
Over 50 comments about minor syntax issue ...
Including yours.
On Thursday, 12 June 2014 at 22:38:26 UTC, Daniel Kozák via
Digitalmars-d wrote:
No problem for me:
http://stackoverflow.com/questions/23950796/how-to-repeat-a-statement-n-times-simple-loop/23952012#23952012
Now put a break statement in the loop body.
On Friday, 13 June 2014 at 15:48:37 UTC, Timon Gehr wrote:
On 06/13/2014 01:55 PM, Dicebot wrote:
Over 50 comments about minor syntax issue ...
Including yours.
That was my first comment in this thread :O
On 6/13/2014 5:15 AM, Jonathan M Davis via Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(; 0..n) {} added.
I don't like special cases like like these.
Disallowing for(;;) would *be* a special case. Each of the three parts
can be individually omitted, and
On Fri, Jun 13, 2014 at 12:54:44PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 6/13/2014 5:15 AM, Jonathan M Davis via Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(; 0..n)
{} added. I don't like special cases like like these.
Disallowing
On Friday, 13 June 2014 at 17:05:26 UTC, H. S. Teoh via
Digitalmars-d wrote:
I don't like arbitrary constants like the `true` in while(true)
-- it kinda goes against the grain, that while implies there
is a stopping point, but sticking true in there contradicts
this notion and is
therefore
On Fri, 13 Jun 2014 14:25:19 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 13 June 2014 at 09:29:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(;
0..n) {} added.
Just out of curiosity,
On Fri, Jun 13, 2014 at 10:46:17AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
for(;;) is a special case with no real benefit IMHO. It's a loop whose
condition is implicitly true rather than actually having a condition
in it. IMHO, it should required to be at least for(;1;) or
On Fri, 13 Jun 2014 13:03:50 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Fri, Jun 13, 2014 at 12:54:44PM -0400, Nick Sabalausky via
Digitalmars-d wrote:
On 6/13/2014 5:15 AM, Jonathan M Davis via Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed
On Fri, 13 Jun 2014 01:27:24 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 13 June 2014 14:14, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Some forward ranges don't have a known length, and can only be summed
by an iteration sweep.
201 - 300 of 811 matches
Mail list logo
