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
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
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
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
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
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
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
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
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
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
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 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:
> >> >
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
>> >
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
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
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
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
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.
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
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
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
21 matches
Mail list logo
