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.

Jakob Bornecrantz:

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

I agree, and in my opinion this should be fixed adding a small note to the D home page, that explains that you should expect every new D version to break your older code and that someday this will stop. Is Andrei agreeing on this small homepage change?

Bye,
bearophile

On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright 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.

I knew that.

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

See this thread, pls:

http://forum.dlang.org/thread/vtpcxubtuquvelsofafy@forum.dlang.org

Also, this link ("C family") for colors and caret:

http://gcc.gnu.org/gcc-4.9/changes.html

clang implemented this and pressure was put on gcc to do the same.

Good and clear diagnostic messages/display are of big help, I think.

On 9/21/13 1:06 PM, bearophile wrote:
> Jakob Bornecrantz:
>
>> 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.
>
> I agree, and in my opinion this should be fixed adding a small note to
> the D home page, that explains that you should expect every new D
> version to break your older code and that someday this will stop. Is
> Andrei agreeing on this small homepage change?

I'm ambivalent because the matter is fuzzy. It is factually true that new releases will break code. On the other hand, that is the case with most compiler releases even for mature languages (at Facebook upgrading across minor gcc releases _always_ entails significant disruption). On the third hand (sic), there are companies and projects using D in the real world so stating that is unstable would do little else than either shoo people away for no good reason.


Andrei

Am 21.09.2013 23:03, schrieb eles:
> On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright 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.
>
> I knew that.
>
>>> 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.
>
> See this thread, pls:
>
> http://forum.dlang.org/thread/vtpcxubtuquvelsofafy@forum.dlang.org
>
> Also, this link ("C family") for colors and caret:
>
> http://gcc.gnu.org/gcc-4.9/changes.html
>
> clang implemented this and pressure was put on gcc to do the same.
>
> Good and clear diagnostic messages/display are of big help, I think.

The funny thing is that this was already supported since a few years in the form of colorgcc.

--
Paulo

Andrei Alexandrescu:

> I'm ambivalent because the matter is fuzzy. It is factually true that new releases will break code. On the other hand, that is the case with most compiler releases even for mature languages (at Facebook upgrading across minor gcc releases _always_ entails significant disruption). On the third hand (sic), there are companies and projects using D in the real world so stating that is unstable would do little else than either shoo people away for no good reason.

While I don't have a solution for that that fuzzy problem, I can express some opinions:
- My technical training has taught me to trust honest lists of problems more than advertisements of technology wonders that break at my first usage;
- I am now keeping lot of D2 code updated and in use, and the work needed to keep it working release after release of dmd was a bit too much for me. If I fix the code only every release there are multiple different sources of breakage and they interact making fixing code harder. I solved that compiling dmd once or more every week. Dmd compiles in a very short time, and I test my whole code base in a short time, both at compile-time and in unittests. Now there only one source of breaking, I know what's the cause of the breaking because it's from the last days of merged patches, and fixing code takes a very short time.
- Often the "breakage" is actually just an exposition of true or latent bugs in my D code. Such "breaking" is welcome and I want more of it.

Bye,
bearophile

On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:
> 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

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.

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

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

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?

On 9/21/2013 2:27 PM, bearophile wrote:
> While I don't have a solution for that that fuzzy problem, I can express some
> opinions:
> - My technical training has taught me to trust honest lists of problems more
> than advertisements of technology wonders that break at my first usage;

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