Recently the EMSI data department upgraded the compiler we use to build our data processing code to 2.074. This caused several of the thousands of processes to die with signal 8 (floating point exceptions). This was caused by the fix to issue 17243.

This is a good thing. We need more breaking changes like this.

Now that the floating point exceptions are properly enabled we were able to track down some issues that were being silently ignored.

On 5/8/17 20:33, Brian Schott wrote:
> Recently the EMSI data department upgraded the compiler we use to build
> our data processing code to 2.074. This caused several of the thousands
> of processes to die with signal 8 (floating point exceptions). This was
> caused by the fix to issue 17243.
>
> This is a good thing. We need more breaking changes like this.
>
> Now that the floating point exceptions are properly enabled we were able
> to track down some issues that were being silently ignored.

WUT.

All I hear on these forums is the abject terror of breaking changes making companies run screaming from D. You mean to say that companies don't actually mind breaking changes if it solves long-standing issues.

I'm shocked. SHOCKED I SAY!

;-)

Can we PLEASE get more of this? I'm not saying up-end the language, but let's solve some problems. I doubt our corporate users will be very angry. I suspect that most reactions will fall between "minor irritation" and this one.

/me looks sideways at shared

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Tuesday, 9 May 2017 at 12:13:34 UTC, Adam Wilson wrote:
> Can we PLEASE get more of this? I'm not saying up-end the language, but let's solve some problems. I doubt our corporate users will be very angry. I suspect that most reactions will fall between "minor irritation" and this one.
>
> /me looks sideways at shared

Here is more of this. Writing industry D code I *love* breaking changes that reveal bugs in the code base.
A while ago I suggested changing cast(bool) semantics of floating-point types so that assert(x) fails if x is NaN (https://issues.dlang.org/show_bug.cgi?id=13489). It was rejected because it could break existing code and surprise C/C++ programmers (although the point of NaN is to surprise you IMHO).
I wonder what the ratio of valid to buggy code is that would break with this change. At least I enjoy it if my buggy code breaks.

On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via Digitalmars-d wrote:
> On 5/8/17 20:33, Brian Schott wrote:
> > Recently the EMSI data department upgraded the compiler we use to build our data processing code to 2.074. This caused several of the thousands of processes to die with signal 8 (floating point exceptions). This was caused by the fix to issue 17243.
> > 
> > This is a good thing. We need more breaking changes like this.
[...]
> WUT.
> 
> All I hear on these forums is the abject terror of breaking changes making companies run screaming from D. You mean to say that companies don't actually mind breaking changes if it solves long-standing issues.
> 
> I'm shocked. SHOCKED I SAY!
> 
> ;-)
> 
> Can we PLEASE get more of this? I'm not saying up-end the language, but let's solve some problems. I doubt our corporate users will be very angry. I suspect that most reactions will fall between "minor irritation" and this one.
> 
> /me looks sideways at shared
[...]

I don't represent any company, but I have to also say that I *appreciate* breaking changes that reveal latent bugs in my code. In fact, I even appreciate breakages that eventually force me to write more readable code!  A not-so-recent example:

	/* Used to work, oh, I forget which version now, but it used to
	 * work: */
	MyType* ptr = ...;
	if (someCondition && ptr) { ... }

After upgrading the compiler, I get a warning that using a pointer as a condition is deprecated.  At first I was mildly annoyed... but then to make the warning go away, I wrote this instead:

	/* Look, ma! Self-documenting, readable code! */
	MyType* ptr = ...;
	if (someCondition && ptr !is null) { ... }

Much more readable, and makes intent so much clearer.  Eventually I was very happy this supposedly "big bad" breaking change was made.

I wish Walter & Andrei & gang would introduce this sort of breakages more often. They will both improve the language and impress users whose code we are so afraid of breaking (I'm still not sure why).


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!

On Tuesday, 9 May 2017 at 17:34:48 UTC, H. S. Teoh wrote:
> On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via Digitalmars-d wrote:
>> > [...]
> [...]
>> [...]
> [...]
>
> I don't represent any company, but I have to also say that I *appreciate* breaking changes that reveal latent bugs in my code. In fact, I even appreciate breakages that eventually force me to write more readable code!  A not-so-recent example:
>
> [...]

The code breakage annoyance has more to do with 3rd party libraries not very actively maintained than with active codebases imho.

On 5/9/17 20:23, Patrick Schluter wrote:
> On Tuesday, 9 May 2017 at 17:34:48 UTC, H. S. Teoh wrote:
>> On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via
>> Digitalmars-d wrote:
>>> > [...]
>> [...]
>>> [...]
>> [...]
>>
>> I don't represent any company, but I have to also say that I
>> *appreciate* breaking changes that reveal latent bugs in my code. In
>> fact, I even appreciate breakages that eventually force me to write
>> more readable code!  A not-so-recent example:
>>
>> [...]
>
> The code breakage annoyance has more to do with 3rd party libraries not
> very actively maintained than with active codebases imho.

*cough* Umm, I think that's a false pointer.

If it's not actively maintained, should you really be relying on it? Where I work, current maintenance is one of the first questions we ask, followed immediately by determining whether or not we are able to maintain it ourselves should it go unmaintained.

If you're going to take on maintenance yourself, the library is already missing features and you're responsible for fixing it's existing implementation bugs anyways, might as well do the work of upgrading it while you're at it.

This is the point of Open Source, we have the opportunity to take unmaintained code and start maintaining it again.

Either way all I hear about is corp users not liking breaking changes. That has been demonstrated as a false concern time and time again.

If it's a matter of unmaintained libraries, those libraries probably have bigger problems than breaking compiler changes, fork and upgrade them or write your own. Because those have always been the only two choices you've ever had in practice anyways. Telling the world that we can't make breaking changes to the compiler because it might break an unmaintained library is irrational position and extreme position to take. It will *not* win us hearts and minds.

Let's stop hiding behind our misplaced fears over corp-users and unmaintained libraries so that we can start improving D for everyone who is using it today.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Wed, May 10, 2017 at 03:19:20AM +0200, Adam Wilson via Digitalmars-d wrote: [...]
> Either way all I hear about is corp users not liking breaking changes. That has been demonstrated as a false concern time and time again.
> 
> If it's a matter of unmaintained libraries, those libraries probably have bigger problems than breaking compiler changes, fork and upgrade them or write your own. Because those have always been the only two choices you've ever had in practice anyways. Telling the world that we can't make breaking changes to the compiler because it might break an unmaintained library is irrational position and extreme position to take. It will *not* win us hearts and minds.
> 
> Let's stop hiding behind our misplaced fears over corp-users and unmaintained libraries so that we can start improving D for everyone who is using it today.
[...]

+1.  Please let's not go down the same path that led C++ to become what it is today: an overly complex language that almost nobody fully understands (and even fewer can write correct code in), yet still suffering under the weight of design mistakes of decades ago. But in spite of all that, it's, oh, backward-compatible!  How wonderful, I can still compile my horribly-broken, memory-leaking, pointer-bug-infested excuse for code that I wrote when I was still in college! Isn't that great?  Oh wait, it just segfaulted.  No biggie, I can fix that easily ... give gimme a minute... uh... um... OK, WHAT has changed since the 90's that I can't do *this* anymore? (5 hours later) I give up, this code is useless.  Why does C++ still bother supporting this crappy excuse for code after 2 decades?!


T

-- 
Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets.  Imagination without skill gives us modern art. -- Tom Stoppard

On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:

> I even appreciate breakages that eventually force me to write more
> readable code!  A not-so-recent example:
>
> 	/* Used to work, oh, I forget which version now, but it used to
> 	 * work: */
> 	MyType* ptr = ...;
> 	if (someCondition && ptr) { ... }
>
> After upgrading the compiler, I get a warning that using a pointer as a
> condition is deprecated.  At first I was mildly annoyed... but then to
> make the warning go away, I wrote this instead:
>
> 	/* Look, ma! Self-documenting, readable code! */
> 	MyType* ptr = ...;
> 	if (someCondition && ptr !is null) { ... }

Can you show an example please. I don't see this being required by 2.074.0 (compiled with -w -de).

Thank you,
Ali

On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote:
> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
>  > I even appreciate breakages that eventually force me to write more
>  >
>  > readable code!  A not-so-recent example:
>  >    /* Used to work, oh, I forget which version now, but it used to
>  >
>  >     * work: */
>  >
>  >    MyType* ptr = ...;
>  >    if (someCondition && ptr) { ... }
>  >
>  > After upgrading the compiler, I get a warning that using a pointer as a
>  > condition is deprecated.  At first I was mildly annoyed... but then to
>  >
>  > make the warning go away, I wrote this instead:
>  >    /* Look, ma! Self-documenting, readable code! */
>  >    MyType* ptr = ...;
>  >    if (someCondition && ptr !is null) { ... }
>
> Can you show an example please. I don't see this being required by
> 2.074.0 (compiled with -w -de).

I think that that's the one that Andrei and Vladimir didn't like, because they actually used the conversion to bool correctly in their code a bunch (whereas most everyone else thought that it was too error prone), and the deprecation ended up being removed.

- Jonathan M Davis

On 05/10/2017 11:49 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote:
>> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:

>>  > After upgrading the compiler, I get a warning that using a pointer as a
>>  > condition is deprecated.

> I think that that's the one that Andrei and Vladimir didn't like, because
> they actually used the conversion to bool correctly in their code a bunch
> (whereas most everyone else thought that it was too error prone), and the
> deprecation ended up being removed.
>
> - Jonathan M Davis

Bummer for H. S. Teoh I guess... :/

Although I prefer explicit over implicit in most cases, I've never graduated from if(p) and still using it happily. :)

Ali