On 9/21/13, Maxim Fomin <maxim@maxim-fomin.ru> wrote:
> (like AAs, scope, shared) are at risk to be seriously changed which is a
> serious problem to the user.

These are already a serious problem to the user when they're broken and under-implemented.

On Saturday, 21 September 2013 at 21:58:44 UTC, bearophile wrote:
> Maxim Fomin:
>
>> Thanks, that is clear. Unfortunately, I cannot say that the explanation improves my attidute to the language - dmd still breaks too often code and some significant features (like AAs, scope, shared) are at risk to be seriously changed which is a serious problem to the user.
>
> The creation of such breaking changes should have priority over (= happen sooner than) most other compiler changes and bug fixes.
>
> Beside AAs, scope, and shared, another smaller example of such breaking changes was discussed a lot today:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11080
> http://d.puremagic.com/issues/show_bug.cgi?id=4733
>

Yes, unfortunately D problems are not limited to those mentioned.

> In Issue 11080 someone has asked to disallow code like:
>
> assert("something going wrong");
>
> But I suggest to not add that rule and instead implement the small breaking change discussed in Issue 4733, that disallows the use of dynamic arrays in all boolean evaluation contexts. So Issue 11080 becomes a special case that needs no special testing code in the compiler.
>
> Bye,
> bearophile

Well, it is an option to ban dynamic arrays in boolean conditions
because the way they are implemented right now is buggy, but I
consider fixing semantic and still keeping syntax to be a better
option comparing to a complete ban.

On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright wrote:
> On 9/21/2013 2:40 PM, Maxim Fomin wrote:
>> Thanks, that is clear. Unfortunately, I cannot say that the explanation improves
>> my attidute to the language - dmd still breaks too often code and some
>> significant features (like AAs, scope, shared) are at risk to be seriously
>> changed which is a serious problem to the user.
>
> I'm curious - was there a logic bug in your code with the overflow, or had that been the intended behavior?

This was bug in gtkd sources when I tried to compile its most recent version (tried even from github) with git-head dmd. I think it is a problem of gtkd developers rather than dmd.

Walter Bright:

> I believe that bugzilla is an honest list of the problems. It's the whole point of bugzilla.

So are you saying that Bugzilla is enough for new or future D users that want to know how much stable D is?

Bye,
bearophile

Maxim Fomin:

> Well, it is an option to ban dynamic arrays in boolean conditions
> because the way they are implemented right now is buggy, but I
> consider fixing semantic and still keeping syntax to be a better
> option comparing to a complete ban.

Right, fixing that semantic is another option I listed in Issue 4733 :-)

Bye,
bearophile

On 9/21/2013 3:27 PM, bearophile wrote:
> Walter Bright:
>
>> I believe that bugzilla is an honest list of the problems. It's the whole
>> point of bugzilla.
>
> So are you saying that Bugzilla is enough for new or future D users that want to
> know how much stable D is?

It's an honest list of the problems, for anyone who wants to look at them, and they can then make up their own mind about stability based on their needs.

On 9/21/2013 3:11 PM, Maxim Fomin wrote:
> On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright wrote:
>> On 9/21/2013 2:40 PM, Maxim Fomin wrote:
>>> Thanks, that is clear. Unfortunately, I cannot say that the explanation improves
>>> my attidute to the language - dmd still breaks too often code and some
>>> significant features (like AAs, scope, shared) are at risk to be seriously
>>> changed which is a serious problem to the user.
>>
>> I'm curious - was there a logic bug in your code with the overflow, or had
>> that been the intended behavior?
>
> This was bug in gtkd sources when I tried to compile its most recent version
> (tried even from github) with git-head dmd. I think it is a problem of gtkd
> developers rather than dmd.

Ok, so it found a latent bug in the source code - I don't think that's a good example of dmd being unstable - it was a good change.

On Sep 21, 2013, at 12:47 PM, Walter Bright <newshound2@digitalmars.com> wrote:

> 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.

Can't you just hold a pointer to the beginning of the line and subtract to find the column?  I agree that it's generally of marginal utility though.

On Saturday, 21 September 2013 at 20:00:52 UTC, Jakob Bornecrantz wrote:
> On Saturday, 21 September 2013 at 18:23:20 UTC, bearophile wrote:
>> 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.
>
> Then again _NOWHERE_ on the start page, the overview page
> or the download* page is the word stable found. On the other
> hand unstable for that matter, none of those pages really
> convey that shit _IS_ going to break every new compiler
> release, proceed with caution.
>
>
> * Stable is found there but referring to the latest GDC release.


I've found my code to not break very frequently anymore even using git head. The last thing that broke any of my code was the stringof change in git head, and that was a 2 minute fix. I think it's been 2-3 minor releases before that at least.

On 9/21/2013 5:11 PM, Sean Kelly wrote:
>> 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.
>
> Can't you just hold a pointer to the beginning of the line and subtract to
> find the column?  I agree that it's generally of marginal utility though.

Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs & Unicode).

Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns.

Then you get a bug report where someone does. So raise it to an unsigned short, then, sigh, you get another bug report where someone's entire source file is on one line, and on it goes.