Re: Thoughts on some code breakage with 2.074

2017-05-12 Thread Steven Schveighoffer via Digitalmars-d
On 5/11/17 7:52 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, May 11, 2017 at 07:46:24PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] But this still doesn't mean that *all* bool conversions are value based. In at least the struct and class cases, more than just the bits are chec

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread H. S. Teoh via Digitalmars-d
On Thu, May 11, 2017 at 07:46:24PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] > But this still doesn't mean that *all* bool conversions are value > based. In at least the struct and class cases, more than just the bits > are checked. [...] Wait, what? You can use a *struct* as a

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread H. S. Teoh via Digitalmars-d
On Thu, May 11, 2017 at 08:21:46AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] > I don't ever remember if(ptr) being deprecated. In fact, I'd go as far > as saying that maybe H.S. Teoh misremembers the array thing as > pointers. > > The biggest reason is that a huge useful pattern

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread Steven Schveighoffer via Digitalmars-d
On 5/11/17 7:12 PM, deadalnix wrote: On Thursday, 11 May 2017 at 12:26:11 UTC, Steven Schveighoffer wrote: if(arr) -> same as if(arr.ptr) Nope. It is: if(arr) -> same as if(((cast(size_t) arr.ptr) | arr.length) != 0) Should we conclude from the fact that absolutely nobody gets it right in th

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread Steven Schveighoffer via Digitalmars-d
On 5/11/17 7:12 PM, deadalnix wrote: On Thursday, 11 May 2017 at 12:26:11 UTC, Steven Schveighoffer wrote: if(arr) -> same as if(arr.ptr) Nope. It is: if(arr) -> same as if(((cast(size_t) arr.ptr) | arr.length) != 0) Should we conclude from the fact that absolutely nobody gets it right in th

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread deadalnix via Digitalmars-d
On Thursday, 11 May 2017 at 12:26:11 UTC, Steven Schveighoffer wrote: if(arr) -> same as if(arr.ptr) Nope. It is: if(arr) -> same as if(((cast(size_t) arr.ptr) | arr.length) != 0) Should we conclude from the fact that absolutely nobody gets it right in this very forum that nobody will get it

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread deadalnix via Digitalmars-d
On Thursday, 11 May 2017 at 12:21:46 UTC, Steven Schveighoffer wrote: I can't imagine anyone attempted to force this to break without a loud backlash. I think if(ptr) is mostly universally understood to mean the pointer is not null. -Steve It is not a problem for pointer because for pointer

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread Steven Schveighoffer via Digitalmars-d
On 5/11/17 5:37 AM, deadalnix wrote: On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote: 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 All bool conversions in D are valu

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread Steven Schveighoffer via Digitalmars-d
On 5/10/17 2:49 PM, 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: > I even appreciate breakages that eventually force me to write more > > readable code! A not-so-

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread Patrick Schluter via Digitalmars-d
On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote: 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 com

Re: Thoughts on some code breakage with 2.074

2017-05-11 Thread deadalnix via Digitalmars-d
On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote: 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 All bool conversions in D are value based, not identity based. Not on

Re: Thoughts on some code breakage with 2.074

2017-05-10 Thread Jonathan M Davis via Digitalmars-d
On Wednesday, May 10, 2017 12:06:40 Ali Çehreli via Digitalmars-d wrote: > 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: > >> > Afte

Re: Thoughts on some code breakage with 2.074

2017-05-10 Thread Ali Çehreli via Digitalmars-d
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 >> > conditi

Re: Thoughts on some code breakage with 2.074

2017-05-10 Thread Jonathan M Davis via Digitalmars-d
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 whi

Re: Thoughts on some code breakage with 2.074

2017-05-10 Thread Ali Çehreli via Digitalmars-d
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 (some

Re: Thoughts on some code breakage with 2.074

2017-05-09 Thread H. S. Teoh via Digitalmars-d
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 probabl

Re: Thoughts on some code breakage with 2.074

2017-05-09 Thread Adam Wilson via Digitalmars-d
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 chan

Re: Thoughts on some code breakage with 2.074

2017-05-09 Thread Patrick Schluter via Digitalmars-d
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.

Re: Thoughts on some code breakage with 2.074

2017-05-09 Thread H. S. Teoh via Digitalmars-d
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

Re: Thoughts on some code breakage with 2.074

2017-05-09 Thread David Eckardt via Digitalmars-d
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 lo

Re: Thoughts on some code breakage with 2.074

2017-05-09 Thread Adam Wilson via Digitalmars-d
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