http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs written down.
Should I continue?

Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all.

On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=11086
> http://d.puremagic.com/issues/show_bug.cgi?id=11010
> http://d.puremagic.com/issues/show_bug.cgi?id=10970
>
> I've found and reported these bugs after about merely 100 LOCs written down.
> Should I continue?
>
> Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all.

Yes, it is unstable and still is advertized as being so. There are significant misfunctioning features which would break code when are fixed, let alone each release breaks something minor. For example, I was pissed off two days ago when git-head dmd rejected to compile large code base due to some 'enum overflow' error. Being watching bugzilla and github for two years, that change was neither expected nor clear for me. Now I see, that two years ago when I abandoned not reach for features but fully stable lang, I was undervaluing neccessity of a lang to be a stable.

Zhouxuan:

> http://d.puremagic.com/issues/show_bug.cgi?id=11086
> http://d.puremagic.com/issues/show_bug.cgi?id=11010
> http://d.puremagic.com/issues/show_bug.cgi?id=10970
>
> I've found and reported these bugs after about merely 100 LOCs written down.

D is not claimed to be stable, or those claims are wrong.

About three years ago I used to find a new compiler bug about every 20 lines of my code. Now the situation is improved a lot and I am able to write more lines before hitting bugs. They have fixed hundreds of the bugs I have submitted, so dmd is now more debugged for the code patterns I usually write. If your code patterns are different from mine, you will see significantly more bugs than me :-)


> Should I continue?

Of course you should continue to submit bugs. Fixing 100+ bugs in every D release is having positive visible effects on the language+compiler. If you submit bugs and they get fixed in some days/weeks/months/years, your code patterns will work more and more.


> Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all.

There is no official roadmap because D is not developed in that way, and because there is not enough workforce. Perhaps someday a roadmap will be present.

Bye,
bearophile

On 9/21/2013 11:03 AM, Maxim Fomin wrote:
> For example, I was pissed off two days ago when
> git-head dmd rejected to compile large code base due to some 'enum overflow'
> error. Being watching bugzilla and github for two years, that change was neither
> expected nor clear for me.

Enum members with no initializer are defined to be set to the previous enum member's value + 1. This, of course, can overflow if the previous value is the max value for the type. For example,

enum E {
    A = int.max,
    B
}

C:\cbx\mars>dmd test
test.d(3): Error: enum member test.E.B overflow of enum value cast(E)2147483647

This change was made because the behavior of ignoring the overflow was listed as a bug.

Since you said it was unclear, how could this be made clear?

------------------------------------
As C code:

enum E {
    A = 2147483647,
    B
};

and gcc reports:

test.c:4: error: overflow in enumeration values

On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=11086
> http://d.puremagic.com/issues/show_bug.cgi?id=11010
> http://d.puremagic.com/issues/show_bug.cgi?id=10970
>
> I've found and reported these bugs after about merely 100 LOCs written down.
> Should I continue?
>
> Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all.

D is not what I would call stable, but it is very usable. Apparently D is used at Facebook in some capacity, but Andrei won't tell us more than that :-)

Not long ago I would find bugs every hour or so, but now I rarely find bugs. Perhaps I have just learned to write code in the subset of D that works well, but the language is definitely a lot more stable.

Please continue to submit bugs. The D contributors do fix bugs very rapidly in general.

On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=11086
> http://d.puremagic.com/issues/show_bug.cgi?id=11010
> http://d.puremagic.com/issues/show_bug.cgi?id=10970
>
> I've found and reported these bugs after about merely 100 LOCs written down.
> Should I continue?
>

I have had similar feelings when I started with D i think. Well, as soon as you see a language which has so many capabilities you've never seen before in one place (reflection and native code - yay!) you start pushing it to the limit. Sometimes you're doing a thing noone even thought about before :).

Exercising the capabilites of D is fun but there are some things which do not work yet. After some experience I've settled on using a simpler subset of D functionality; both because I think simpler sollutions are better and because simpler parts of D tend to work very well.

Go ahead and report more bugs, this is improving the situation in longer term. People which will use D after you will be glad you've spent a little time on doing that because their experience will be smoother. It'd be nice if D was perfect already but things simply take a lot of time and effort to be done. It's hard to compete with already mature enviroments because of that.

> Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all.

As for containers there's std.container and builtin arrays and hasmaps - that's somewhat a poor set, but you can use container libraries from github.

Containers as planned for phobos need solving the issue of allocators for them.  Andrei which is working on them is probably stuck in void somewhere between compiletime and runtime worlds :)

On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:
> On 9/21/2013 11:03 AM, Maxim Fomin wrote:
>
> test.c:4: error: overflow in enumeration values

It would be difficult to make the front-end track also the column number where it encountered (estimated) the error?

This will make error messages a bit more clear (and in the line of thos in gcc), especially for long code lines (where you could have, for example, several instructions on the line).

At the beginning, until the feature is really implemented, the front-end could always provide "column=1", ie stick with current approach.

But this will help the gdc/ldc-implementations to be in line with the messages provided by gcc and clang.

On 9/21/2013 12:38 PM, eles wrote:
> On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:
>> On 9/21/2013 11:03 AM, Maxim Fomin wrote:
>>
>> test.c:4: error: overflow in enumeration values
>
> It would be difficult to make the front-end track also the column number where
> it encountered (estimated) the error?

That's gcc, and 4 is the line number (and the wrong line number) of the error. No column number.

> This will make error messages a bit more clear (and in the line of thos in gcc),
> especially for long code lines (where you could have, for example, several
> instructions on the line).
>
> At the beginning, until the feature is really implemented, the front-end could
> always provide "column=1", ie stick with current approach.
>
> But this will help the gdc/ldc-implementations to be in line with the messages
> provided by gcc and clang.

Tracking the column number is certainly doable, but it comes at a cost of memory consumption and some compile speed, since it has to be tracked in every token. I used to do it in the Digital Mars C compiler, but it was of only marginal utility and I dropped it.

On 9/21/2013 10:41 AM, Zhouxuan wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=11086
> http://d.puremagic.com/issues/show_bug.cgi?id=11010
> http://d.puremagic.com/issues/show_bug.cgi?id=10970
>
> I've found and reported these bugs after about merely 100 LOCs written down.
> Should I continue?
>
> Despite these tiny issues, I see a lot of people complain about container, GC
> etc, but I can't found any offical reply, also no roadmap at all.

Thanks for taking the time to make some nice bug reports. They're a big help.

On 9/21/13 12:28 PM, QAston wrote:
> Containers as planned for phobos need solving the issue of allocators
> for them.  Andrei which is working on them is probably stuck in void
> somewhere between compiletime and runtime worlds :)

FWIW I am making solid progress on allocators. In places the design comes together really really unexpectedly nice.

To the original poster: thanks for submitting those bugs. They concern simple code and it is an embarrassment for us that this kind of "out-of-the-box experience" bugs still appear.


Andrei