www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Language Gotchas

reply "Sumit Adhikari" <sumit.adhikari gmail.com> writes:
Dear All,

I searched internet also I searched this forum for D Language 
gotchas. In this forum, I found a thread which is from 2005 and I 
do not know latest updates on that.

My question is that - "Are there known programming gotchas of D 
language ?"

If will be grateful if I get some pointers.

Regards, Sumit
Nov 04 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 5 November 2013 at 02:59:55 UTC, Sumit Adhikari wrote:

 Dear All,

 I searched internet also I searched this forum for D Language 
 gotchas. In this forum, I found a thread which is from 2005 and 
 I do not know latest updates on that.

 My question is that - "Are there known programming gotchas of D 
 language ?"


We have probably enough to create an OuOfMemooryError in your 
browser.


 If will be grateful if I get some pointers.


GC.alloc will give you plenty :D

Seriously, you gotta limit somehow the scope of that question.
Nov 04 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Tuesday, 5 November 2013 at 02:59:55 UTC, Sumit Adhikari wrote:

 I searched internet also I searched this forum for D Language 
 gotchas. In this forum, I found a thread which is from 2005 and 
 I do not know latest updates on that.

 My question is that - "Are there known programming gotchas of D 
 language ?"

 If will be grateful if I get some pointers.


There are various gotchas due to bugs in the frontend, but they 
get fixed (slowly). You can browse the bug tracker.

Some "gotchas" are just assumptions people have coming from other 
programming languages (slices behavior, floating point, etc). My 
pragmatic tutorial [0] tries to guide you around those.

Some aspects of D are bad in hindsight, but will not be fixed in 
the near future due to backwards compatability. For example, 
 safe and pure should probably have been the defaults instead of 
extra annotations.

[0] http://qznc.github.io/d-tut/
Nov 04 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
I think, all languages have more gotchas than features, because 
features are designed for certain scenarios, so they are likely 
to not play as well in other scenarios, probably more numerous.
Nov 05 2013
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 5 November 2013 at 02:59:55 UTC, Sumit Adhikari wrote:

 Dear All,

 I searched internet also I searched this forum for D Language 
 gotchas. In this forum, I found a thread which is from 2005 and 
 I do not know latest updates on that.

 My question is that - "Are there known programming gotchas of D 
 language ?"

 If will be grateful if I get some pointers.

 Regards, Sumit


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.
Nov 05 2013
parent reply Jacob Carlborg <doob me.com> writes:
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.

-- 
/Jacob Carlborg
Nov 05 2013
next sibling parent reply "Sumit Adhikari" <sumit.adhikari gmail.com> writes:
One big gotcha of this forum is that when I reply I will have to 
reply only one person and hence I cannot thank everybody using 
one mail!

Indeed I am happy that I have some pointers and I thank everybody 
for participation. My need was to create a qualitative analysis 
document for the case of one out of three languages - D, C++ and 
something-else.

I will investigate more and come back to you people if I am stuck.

Regards, Sumit


On Tuesday, 5 November 2013 at 12:27:55 UTC, 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.
Nov 05 2013
parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 5 November 2013 at 13:07:26 UTC, Sumit Adhikari wrote:

 Indeed I am happy that I have some pointers and I thank 
 everybody for participation. My need was to create a 
 qualitative analysis document for the case of one out of three 
 languages - D, C++ and something-else.


You can search for bearophile's enhancement requests in bugzilla. 
They are often aimed at improving D design with respect to C 
legacy, which D has a little. One example is 
http://d.puremagic.com/issues/show_bug.cgi?id=4077
Nov 05 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 05 2013
next sibling parent "Kagamin" <spam here.lot> writes:
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.
Nov 06 2013
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
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.
Nov 06 2013
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 5 November 2013 at 12:27:55 UTC, 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.


It's a combination of [0, 1, 2] allocating and enum a = [0, 1, 2] 
not doing what you think it does (defining a variable instead of 
just copying and pasting).
Nov 05 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 05 2013
parent reply "qznc" <qznc web.de> writes:
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]);
Nov 05 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 05 2013
prev sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
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);
}


request.
Nov 05 2013
parent "Meta" <jared771 gmail.com> writes:
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);
 }


 request.


Also this:

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