One other gotcha that I've run into is trying to use foreach on a range of tuples with an iteration index. It does not do what you might expect, try:
import std.range, std.stdio;
void main()
{
	auto a = repeat(1,5);
	auto b = repeat(2,5);
	foreach(i, ab; a.zip(b)) writeln(i, " ", ab);
}

See bugzilla #5550 for bearophile's range.enumerate enhancement request.

On Tuesday, 5 November 2013 at 17:14:23 UTC, safety0ff wrote:
> One other gotcha that I've run into is trying to use foreach on a range of tuples with an iteration index. It does not do what you might expect, try:
> import std.range, std.stdio;
> void main()
> {
> 	auto a = repeat(1,5);
> 	auto b = repeat(2,5);
> 	foreach(i, ab; a.zip(b)) writeln(i, " ", ab);
> }
>
> See bugzilla #5550 for bearophile's range.enumerate enhancement request.

Also this:

http://d.puremagic.com/issues/show_bug.cgi?id=10765

On Tuesday, November 05, 2013 13:27:54 Jacob Carlborg wrote:
> On 2013-11-05 12:16, Meta wrote:
> > One gotcha relates to enums. Writing `enum a = [0, 1, 2]` is a really bad idea, because everywhere you use a, it constructs a new array at runtime. The [0, 1, 2] is "pasted in", and you'll have a bunch of allocations you didn't expect. This doesn't just happen with arrays, but that's the most common case. What *is* okay is using string enums, as strings are a bit special due to being immutable.
> 
> Isn't the problem rather that [0, 1, 2] allocates in the first place, regardless if an enum is used or not.

In most cases, array literals need to allocate, regardless of whether they're an enum or not. The cases where they don't need to allocate (e.g. when initializing a static array) shouldn't allocate, but an array literal by itself is a dynamic array, and pretty much has to allocate in most cases in order to be safe. Having an enum which is an array literal rather than making it an immutable constant then results in allocations that you might not want, but that's not really the literal's fault.

- Jonathan M Davis

On Wednesday, 6 November 2013 at 04:57:57 UTC, Jonathan M Davis wrote:
> On Tuesday, November 05, 2013 13:27:54 Jacob Carlborg wrote:
>> On 2013-11-05 12:16, Meta wrote:
>> > One gotcha relates to enums. Writing `enum a = [0, 1, 2]` is a really
>> > bad idea, because everywhere you use a, it constructs a new array at
>> > runtime. The [0, 1, 2] is "pasted in", and you'll have a bunch of
>> > allocations you didn't expect. This doesn't just happen with arrays, but
>> > that's the most common case. What *is* okay is using string enums, as
>> > strings are a bit special due to being immutable.
>> 
>> Isn't the problem rather that [0, 1, 2] allocates in the first place,
>> regardless if an enum is used or not.
>
> In most cases, array literals need to allocate, regardless of whether they're
> an enum or not. The cases where they don't need to allocate (e.g. when
> initializing a static array) shouldn't allocate, but an array literal by
> itself is a dynamic array, and pretty much has to allocate in most cases in
> order to be safe. Having an enum which is an array literal rather than making
> it an immutable constant then results in allocations that you might not want,
> but that's not really the literal's fault.

Can you work around that? Maybe something like:

  enum a = immutable([0, 1, 2]);

On Wednesday, November 06, 2013 07:26:57 qznc wrote:
> On Wednesday, 6 November 2013 at 04:57:57 UTC, Jonathan M Davis
> 
> wrote:
> > On Tuesday, November 05, 2013 13:27:54 Jacob Carlborg wrote:
> >> On 2013-11-05 12:16, Meta wrote:
> >> > One gotcha relates to enums. Writing `enum a = [0, 1, 2]` is
> >> > a really
> >> > bad idea, because everywhere you use a, it constructs a new
> >> > array at
> >> > runtime. The [0, 1, 2] is "pasted in", and you'll have a
> >> > bunch of
> >> > allocations you didn't expect. This doesn't just happen with
> >> > arrays, but
> >> > that's the most common case. What *is* okay is using string
> >> > enums, as
> >> > strings are a bit special due to being immutable.
> >> 
> >> Isn't the problem rather that [0, 1, 2] allocates in the first
> >> place,
> >> regardless if an enum is used or not.
> > 
> > In most cases, array literals need to allocate, regardless of
> > whether they're
> > an enum or not. The cases where they don't need to allocate
> > (e.g. when
> > initializing a static array) shouldn't allocate, but an array
> > literal by
> > itself is a dynamic array, and pretty much has to allocate in
> > most cases in
> > order to be safe. Having an enum which is an array literal
> > rather than making
> > it an immutable constant then results in allocations that you
> > might not want,
> > but that's not really the literal's fault.
> 
> Can you work around that? Maybe something like:
> 
>    enum a = immutable([0, 1, 2]);

What's to work around? It's very much on purpose that enums work that way. If you don't want that behavior, then simply create a variable instead. e.g.

immutable a = [0, 1, 2];

The fact that enums are treated as manifest constants isn't a problem so long as you understand that that's what they're supposed to do. If you don't want a manifest constant, then don't use an enum. The only thing that

enum a = [0, 1, 2];

gains you over

immutable a = [0, 1, 2];

is making it a manifest constant instead of a variable. Which you choose depends on what behavior you want. Neither is wrong, and which is desirable depends entirely on what you're doing.

- Jonathan M Davis

On Tuesday, 5 November 2013 at 16:45:53 UTC, bearophile wrote:
> Some better examples:
> http://d.puremagic.com/issues/show_bug.cgi?id=5409
> http://d.puremagic.com/issues/show_bug.cgi?id=3827
> http://d.puremagic.com/issues/show_bug.cgi?id=8757

Those are not implemented, so no difference with C yet except for C compilers warnings.

On Tuesday, 5 November 2013 at 16:45:53 UTC, bearophile wrote:
> Kagamin:
>
>> One example is http://d.puremagic.com/issues/show_bug.cgi?id=4077
>
> Some better examples:
> http://d.puremagic.com/issues/show_bug.cgi?id=5409
> http://d.puremagic.com/issues/show_bug.cgi?id=3827
> http://d.puremagic.com/issues/show_bug.cgi?id=8757
> ...
>
> Bye,
> bearophile

All of these once implemented would add great value to the compiler.