www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - if(arr) now a warning

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
A confusing and dangerous "feature" of D was to treat the expression 
if(arr) as meaning if(arr.ptr).

Anyone coming from any number of other languages may think that if(arr) 
means "if arr has any elements". Typically one cares what is inside an 
array, not where it lives.

However, while checking to see if an array has elements is very similar 
to checking for a null pointer (obviously, a null pointer array should 
have no elements), it's not equivalent. Therefore, when attempting to 
fix this confusion, we had to disable the if(arr) check altogether. You 
must now specify what part of the array you care about, if(arr.ptr) or 
if(arr.length).

As usual with changes of this nature, there are differing opinions, and 
differing styles. I personally never use null as a special value for an 
array, but others do. They use if(arr) to actually mean if(arr.ptr). For 
these cases, the update will cause some amount of busywork changing 
these checks.

But when updating Phobos to comply with this change, we found several 
actual incorrect usages. So I think the change is worth it, and not much 
busywork. YMMV.

What do you think?

references:

https://issues.dlang.org/show_bug.cgi?id=4733
https://github.com/D-Programming-Language/dmd/pull/2885
https://github.com/D-Programming-Language/tools/pull/166

-Steve
Apr 09 2015
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:


 What do you think?


I asked for this fix almost five years ago, so I think it's about 
time :-)

Bye,
bearophile
Apr 09 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 09, 2015 at 04:59:00PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:

 A confusing and dangerous "feature" of D was to treat the expression
 if(arr) as meaning if(arr.ptr).


[...]

 Therefore, when attempting to fix this confusion, we had to disable
 the if(arr) check altogether. You must now specify what part of the
 array you care about, if(arr.ptr) or if(arr.length).


[...]

 But when updating Phobos to comply with this change, we found several
 actual incorrect usages. So I think the change is worth it, and not
 much busywork.  YMMV.


[...]

I agree it's worth it. It's one of the very legitimate reasons for
breaking code IMO. Or rather, to bring to the user's attention code that
likely already contains latent bugs.

Sure some people will complain about it, but in the long run, I think
they will come to appreciate the improved code correctness that this
confers.

It's akin to a similar change sometime ago that made bare pointers in
if-conditions illegal: writing `if (ptr && ...)` will cause the compiler
to complain loudly. When this first got in, one of my projects broke,
and I was rather annoyed at the time. However, when I got around to
fixing it, I found that I had to write `if (ptr !is null && ...)`
instead, which greatly clarifies the intent and readability of the code.
Since then, I have come to appreciate this change.

So this gets a thumbs up from me.


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Apr 09 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.1388.1428620346.3111.digitalmars-d puremagic.com...


 It's akin to a similar change sometime ago that made bare pointers in
 if-conditions illegal: writing `if (ptr && ...)` will cause the compiler
 to complain loudly. When this first got in, one of my projects broke,
 and I was rather annoyed at the time. However, when I got around to
 fixing it, I found that I had to write `if (ptr !is null && ...)`
 instead, which greatly clarifies the intent and readability of the code.
 Since then, I have come to appreciate this change.


Except that never happened.  Maybe you're thinking of comparing objects to 
null with ==?
Apr 09 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 10, 2015 at 01:01:48PM +1000, Daniel Murphy via Digitalmars-d wrote:

 "H. S. Teoh via Digitalmars-d"  wrote in message
 news:mailman.1388.1428620346.3111.digitalmars-d puremagic.com...
 

It's akin to a similar change sometime ago that made bare pointers in
if-conditions illegal: writing `if (ptr && ...)` will cause the
compiler to complain loudly. When this first got in, one of my
projects broke, and I was rather annoyed at the time. However, when I
got around to fixing it, I found that I had to write `if (ptr !is
null && ...)` instead, which greatly clarifies the intent and
readability of the code.  Since then, I have come to appreciate this
change.


 
 Except that never happened.  Maybe you're thinking of comparing
 objects to null with ==?


Are you sure?

My original failing code was:

	while (!lex.empty &&
		(op = T.matchOp(lex.front, OpType.infix)) &&
		op.precedence >= minprec)
	{
		...
	}

where op is a pointer type.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi
Apr 09 2015
next sibling parent "Temtaime" <temtaime gmail.com> writes:
Using an array type in boolean contexts is bug-prone.
Please just write « arr.length » of anything you want.
If you want to see a reasons to forbid it - look at original bug 
report.
Apr 10 2015
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.1397.1428640119.3111.digitalmars-d puremagic.com...


 Are you sure?


Pretty sure.


 My original failing code was:

 while (!lex.empty &&
 (op = T.matchOp(lex.front, OpType.infix)) &&
 op.precedence >= minprec)
 {
 ...
 }

 where op is a pointer type.


Maybe an 'assignment cannot be used as a condition' error?  Nothing to do 
with pointer types as boolean conditions.

eg if (x = call()) -> if ((x = call()) != null)

Do you have a complete example that gives the error you're talking about?
Apr 10 2015
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer 
wrote:

 A confusing and dangerous "feature" of D was to treat the 
 expression if(arr) as meaning if(arr.ptr).

 Anyone coming from any number of other languages may think that 
 if(arr) means "if arr has any elements". Typically one cares 
 what is inside an array, not where it lives.

 However, while checking to see if an array has elements is very 
 similar to checking for a null pointer (obviously, a null 
 pointer array should have no elements), it's not equivalent. 
 Therefore, when attempting to fix this confusion, we had to 
 disable the if(arr) check altogether. You must now specify what 
 part of the array you care about, if(arr.ptr) or if(arr.length).

 As usual with changes of this nature, there are differing 
 opinions, and differing styles. I personally never use null as 
 a special value for an array, but others do. They use if(arr) 
 to actually mean if(arr.ptr). For these cases, the update will 
 cause some amount of busywork changing these checks.

 But when updating Phobos to comply with this change, we found 
 several actual incorrect usages. So I think the change is worth 
 it, and not much busywork. YMMV.

 What do you think?

 references:

 https://issues.dlang.org/show_bug.cgi?id=4733
 https://github.com/D-Programming-Language/dmd/pull/2885
 https://github.com/D-Programming-Language/tools/pull/166

 -Steve


This change meens I had to rewrite almost 1k lines of code which 
almost every one has been wrong :D.

I have lot of code rewriten from php directly to D.

PHP:
http://sandbox.onlinephpfunctions.com/code/b75620f9714784bd888b365b963723a1dc773d08

D:
http://dpaste.dzfl.pl/89f762890526
Apr 10 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-04-09 22:59, Steven Schveighoffer wrote:


 As usual with changes of this nature, there are differing opinions, and
 differing styles. I personally never use null as a special value for an
 array, but others do. They use if(arr) to actually mean if(arr.ptr). For
 these cases, the update will cause some amount of busywork changing
 these checks.

 But when updating Phobos to comply with this change, we found several
 actual incorrect usages. So I think the change is worth it, and not much
 busywork. YMMV.

 What do you think?


I'm wondering how often in practice .ptr is not null but the array is empty.

-- 
/Jacob Carlborg
Apr 10 2015
next sibling parent "biozic" <dransic gmail.com> writes:
On Friday, 10 April 2015 at 08:38:00 UTC, Jacob Carlborg wrote:

 On 2015-04-09 22:59, Steven Schveighoffer wrote:


 As usual with changes of this nature, there are differing 
 opinions, and
 differing styles. I personally never use null as a special 
 value for an
 array, but others do. They use if(arr) to actually mean 
 if(arr.ptr). For
 these cases, the update will cause some amount of busywork 
 changing
 these checks.

 But when updating Phobos to comply with this change, we found 
 several
 actual incorrect usages. So I think the change is worth it, 
 and not much
 busywork. YMMV.

 What do you think?


 I'm wondering how often in practice .ptr is not null but the 
 array is empty.


When you remove elements from arrays: you end up with slices of 
length 0 that have a non-null .ptr. Not that rare.
Apr 10 2015
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 10 April 2015 at 08:38:00 UTC, Jacob Carlborg wrote:

 On 2015-04-09 22:59, Steven Schveighoffer wrote:


 As usual with changes of this nature, there are differing 
 opinions, and
 differing styles. I personally never use null as a special 
 value for an
 array, but others do. They use if(arr) to actually mean 
 if(arr.ptr). For
 these cases, the update will cause some amount of busywork 
 changing
 these checks.

 But when updating Phobos to comply with this change, we found 
 several
 actual incorrect usages. So I think the change is worth it, 
 and not much
 busywork. YMMV.

 What do you think?


 I'm wondering how often in practice .ptr is not null but the 
 array is empty.


Well every time anyone has:

arr[n..m]

where n == m, for a start. That includes every slice that's been 
popFront'd to exhaustion.
Apr 10 2015
parent "JN" <666total wp.pl> writes:
For me personally "if (arr)" means "if I have a non-null array 
and there is something inside", so that something like while 
(arr) { remove_element(arr[0]); } would also work. Same way it 
works in Python, where:

a = None
if (a) // evaluates to false

a = []
if (a) // evaluates to false

a = [5]
if (a) // evaluates to true
Apr 10 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 4:38 AM, Jacob Carlborg wrote:

 On 2015-04-09 22:59, Steven Schveighoffer wrote:


 As usual with changes of this nature, there are differing opinions, and
 differing styles. I personally never use null as a special value for an
 array, but others do. They use if(arr) to actually mean if(arr.ptr). For
 these cases, the update will cause some amount of busywork changing
 these checks.

 But when updating Phobos to comply with this change, we found several
 actual incorrect usages. So I think the change is worth it, and not much
 busywork. YMMV.

 What do you think?


 I'm wondering how often in practice .ptr is not null but the array is
 empty.


assert("".ptr);

-Steve
Apr 10 2015
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
I think it's worth changing this.

if (arr)

translating to

if (arr.length == 0)

Is immediately obvious for anyone coming from at least a Python 
background. I have implemented my own hashmaps in a similar way. 
For my maps, the length is stored in the map so it can be 
retrieved in O(1) time, and cast(bool) results in map.length == 
0. (This extends also to empty sets.)

If we need a deprecation path, we can do it. We just warn about 
if (arr) for a while, so you are told to use if(arr.length == 0) 
or if (arr.ptr is null) for a while, then we change the behaviour 
in another release.
Apr 10 2015
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 10 April 2015 at 09:27:56 UTC, w0rp wrote:

 If we need a deprecation path, we can do it. We just warn about 
 if (arr) for a while, so you are told to use if(arr.length == 
 0) or if (arr.ptr is null) for a while, then we change the 
 behaviour in another release.


That's kind of the roadmap, though we'd need to wait quite a 
while until we can reuse it.
I've been thinking about moving std.array.empty to object. Then 
that could more easily become the replacement idiom.

if (arr) -> if (!arr.empty)

It's much clearer and also what you need to write when you work 
with ranges.
Apr 10 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Martin Nowak"  wrote in message 
news:lgjobvhvilvdymfatoje forum.dlang.org...


 I've been thinking about moving std.array.empty to object. Then that could 
 more easily become the replacement idiom.

 if (arr) -> if (!arr.empty)

 It's much clearer and also what you need to write when you work with 
 ranges.


if (arr.length) is just as clear, and the same thing.

I use arr.length when I'm working with arrays, and .empty when working with 
general ranges.  I generally prefer not to mix the two.
Apr 10 2015
next sibling parent reply "Martin Krejcirik" <mk-junk i-line.cz> writes:
On Friday, 10 April 2015 at 10:30:13 UTC, Daniel Murphy wrote:

 if (arr.length) is just as clear, and the same thing.


I agree, people should just use arr.length. I would leave it as 
it is now, that is forever warning on if (arr).
Apr 10 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Martin Krejcirik:


 I agree, people should just use arr.length.


People should probably use "arr.empty".

Bye,
bearophile
Apr 10 2015
next sibling parent "Namespace" <rswhite4 gmail.com> writes:
On Friday, 10 April 2015 at 11:18:16 UTC, bearophile wrote:

 Martin Krejcirik:


 I agree, people should just use arr.length.


 People should probably use "arr.empty".

 Bye,
 bearophile


Comes to the same thing: 
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L1957
Apr 10 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-04-10 13:18, bearophile wrote:

 People should probably use "arr.empty".


We should have an opposite of "empty". Something like "arr.any" or similar.

-- 
/Jacob Carlborg
Apr 10 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 7:18 AM, bearophile wrote:

 Martin Krejcirik:


 I agree, people should just use arr.length.


 People should probably use "arr.empty".


empty is a negative. I'd prefer if(arr.length) instead of 
if(!arr.empty), as the latter's a double-negative.

Plus, adding arr.empty into object is kind of redundant. The only reason 
we have arr.empty is so that it becomes a range.

-Steve
Apr 10 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer 
wrote:

 Plus, adding arr.empty into object is kind of redundant. The 
 only reason we have arr.empty is so that it becomes a range.

 -Steve


I find it extremely annoying to have to import std.array (or 
whatever the correct module is) just to use .empty, .front and 
.popFront on arrays. IMO they should all be in object.d.
Apr 10 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 9:26 AM, Meta wrote:

 On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:

 Plus, adding arr.empty into object is kind of redundant. The only
 reason we have arr.empty is so that it becomes a range.


 I find it extremely annoying to have to import std.array (or whatever
 the correct module is) just to use .empty, .front and ..popFront on
 arrays. IMO they should all be in object.d.


If only it were that easy... The problem is char[] (or rather, the 
insistence of Phobos that char[] is not an array).

-Steve
Apr 10 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/15 6:26 AM, Meta wrote:

 On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:

 Plus, adding arr.empty into object is kind of redundant. The only
 reason we have arr.empty is so that it becomes a range.

 -Steve


 I find it extremely annoying to have to import std.array (or whatever
 the correct module is) just to use .empty, .front and .popFront on
 arrays. IMO they should all be in object.d.


Yah, I was about to post the same. Range semantics are embedded in the 
language enough to warrant this.

Also empty should work for AAs.


Andrei
Apr 10 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 11:57 AM, Andrei Alexandrescu wrote:

 On 4/10/15 6:26 AM, Meta wrote:

 On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:

 Plus, adding arr.empty into object is kind of redundant. The only
 reason we have arr.empty is so that it becomes a range.

 -Steve


 I find it extremely annoying to have to import std.array (or whatever
 the correct module is) just to use .empty, .front and .popFront on
 arrays. IMO they should all be in object.d.


 Yah, I was about to post the same. Range semantics are embedded in the
 language enough to warrant this.

 Also empty should work for AAs.


How should "abc".front work? Do you want to move unicode decoding of 
char and wchar arrays into object.d? Serious question, not rhetorical, 
because I'm not for or against it (except for the notion of changing 
things for the sake of changing them), I just want to point out what is 
required.

-Steve
Apr 10 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/15 10:28 AM, Steven Schveighoffer wrote:

 On 4/10/15 11:57 AM, Andrei Alexandrescu wrote:

 On 4/10/15 6:26 AM, Meta wrote:

 On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:

 Plus, adding arr.empty into object is kind of redundant. The only
 reason we have arr.empty is so that it becomes a range.

 -Steve


 I find it extremely annoying to have to import std.array (or whatever
 the correct module is) just to use .empty, .front and .popFront on
 arrays. IMO they should all be in object.d.


 Yah, I was about to post the same. Range semantics are embedded in the
 language enough to warrant this.

 Also empty should work for AAs.


 How should "abc".front work? Do you want to move unicode decoding of
 char and wchar arrays into object.d? Serious question, not rhetorical,
 because I'm not for or against it (except for the notion of changing
 things for the sake of changing them), I just want to point out what is
 required.


Should decode. Meaning there's no change of semantics, just where the 
facility is defined. -- Andrei
Apr 10 2015
parent reply "w0rp" <devw0rp gmail.com> writes:
On Friday, 10 April 2015 at 18:32:39 UTC, Andrei Alexandrescu 
wrote:

 On 4/10/15 10:28 AM, Steven Schveighoffer wrote:

 On 4/10/15 11:57 AM, Andrei Alexandrescu wrote:

 On 4/10/15 6:26 AM, Meta wrote:

 On Friday, 10 April 2015 at 12:42:47 UTC, Steven 
 Schveighoffer wrote:

 Plus, adding arr.empty into object is kind of redundant. 
 The only
 reason we have arr.empty is so that it becomes a range.

 -Steve


 I find it extremely annoying to have to import std.array (or 
 whatever
 the correct module is) just to use .empty, .front and 
 .popFront on
 arrays. IMO they should all be in object.d.


 Yah, I was about to post the same. Range semantics are 
 embedded in the
 language enough to warrant this.

 Also empty should work for AAs.


 How should "abc".front work? Do you want to move unicode 
 decoding of
 char and wchar arrays into object.d? Serious question, not 
 rhetorical,
 because I'm not for or against it (except for the notion of 
 changing
 things for the sake of changing them), I just want to point 
 out what is
 required.


 Should decode. Meaning there's no change of semantics, just 
 where the facility is defined. -- Andrei


Having thought about it more, I think that is why we cannot put 
the range primitives for slices into object.d. Because that makes 
it impossible to define the primitives differently, so that no 
auto-decoding occurs. At the moment, auto-decoding isn't part of 
the language, it's just written in to the standard library. This 
would change that.
Apr 11 2015
next sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/11/2015 01:03 PM, w0rp wrote:

 At the moment, auto-decoding isn't part of the language


That won't change anytime soon.
Apr 11 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/11/15 4:03 AM, w0rp wrote:

 Having thought about it more, I think that is why we cannot put the
 range primitives for slices into object.d. Because that makes it
 impossible to define the primitives differently, so that no
 auto-decoding occurs. At the moment, auto-decoding isn't part of the
 language, it's just written in to the standard library. This would
 change that.


That's where it should be. -- Andrei
Apr 11 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/10/2015 07:28 PM, Steven Schveighoffer wrote:

 Also empty should work for AAs.


 
 How should "abc".front work? Do you want to move unicode decoding of
 char and wchar arrays into object.d?


We already have unicode decoding in druntime, the old and slow version
though. Wouldn't cost much to move those 2 functions.
Also we now have core.internal for more contrived stuff, works like this.
https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L697
Apr 10 2015
prev sibling parent "w0rp" <devw0rp gmail.com> writes:
On Friday, 10 April 2015 at 15:57:09 UTC, Andrei Alexandrescu 
wrote:

 On 4/10/15 6:26 AM, Meta wrote:

 On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer 
 wrote:

 Plus, adding arr.empty into object is kind of redundant. The 
 only
 reason we have arr.empty is so that it becomes a range.

 -Steve


 I find it extremely annoying to have to import std.array (or 
 whatever
 the correct module is) just to use .empty, .front and 
 .popFront on
 arrays. IMO they should all be in object.d.


 Yah, I was about to post the same. Range semantics are embedded 
 in the language enough to warrant this.

 Also empty should work for AAs.


 Andrei


I was going to suggest this myself, but I thought it would be too 
much. Having to import std.array to make std.algorithm work with 
slices is a bit of a curve ball for very new D programmers. They 
tend to do this...

import std.algorithm;

void main() {
     int[] arr = [1, 2, 3];

     arr = arr.map!(x => x * 2);
}

Then they get a compile time error and ask why it didn't work. It 
doesn't matter too much, but it is something you have to learn on 
your first day or so.
Apr 10 2015
prev sibling parent reply Andre Kostur <andre kostur.net> writes:
On 2015-04-10 5:42 AM, Steven Schveighoffer wrote:

 empty is a negative. I'd prefer if(arr.length) instead of
 if(!arr.empty), as the latter's a double-negative.


Hmm.  I've never thought of empty as a negative.  For me empty says 
"This thing has the property/state of being empty", not "this thing has 
a corresponding length (or size) of not 0".  Thus if (!arr.empty) is 
only a single negative for me.  "This thing does not have the state of 
being empty."
Apr 10 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 10:53 AM, Andre Kostur wrote:

 On 2015-04-10 5:42 AM, Steven Schveighoffer wrote:

 empty is a negative. I'd prefer if(arr.length) instead of
 if(!arr.empty), as the latter's a double-negative.


 Hmm.  I've never thought of empty as a negative.  For me empty says
 "This thing has the property/state of being empty", not "this thing has
 a corresponding length (or size) of not 0".  Thus if (!arr.empty) is
 only a single negative for me.  "This thing does not have the state of
 being empty."


empty means having nothing. In other words, if something is not empty, 
it doesn't have nothing in it.

It's the way I see it anyway. When I want to check for the presence of 
something, I don't want to say it by checking for the lack of nothing.

There, I'm confused now :)

-Steve
Apr 10 2015
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Martin Krejcirik"  wrote in message 
news:zcyuydcpyfjrbojzjusg forum.dlang.org...


 I agree, people should just use arr.length. I would leave it as it is now, 
 that is forever warning on if (arr).


Yeah, even if we never get to deprecation/error/change of semantics the 
warning will be an improvement.
Apr 10 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 10 Apr 2015 20:30:16 +1000, Daniel Murphy wrote:


 "Martin Nowak"  wrote in message
 news:lgjobvhvilvdymfatoje forum.dlang.org...
=20

 I've been thinking about moving std.array.empty to object. Then that
 could more easily become the replacement idiom.

 if (arr) -> if (!arr.empty)

 It's much clearer and also what you need to write when you work with
 ranges.


=20
 if (arr.length) is just as clear, and the same thing.
=20
 I use arr.length when I'm working with arrays, and .empty when working
 with general ranges.  I generally prefer not to mix the two.


isn't it a compiler task to track types? ranges can be empty, arrays can=20
be empty. i can't see why one should remember that their emptiness if=20
somehow different.=
Apr 10 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"ketmar"  wrote in message news:mg8hda$2rs$12 digitalmars.com...


 I use arr.length when I'm working with arrays, and .empty when working
 with general ranges.  I generally prefer not to mix the two.


 isn't it a compiler task to track types? ranges can be empty, arrays can
 be empty. i can't see why one should remember that their emptiness if
 somehow different.


Nobody said you have to remember anything, it's a style choice.

It's like this code:

uint x;

if (x > 0) {}

if (x != 0) {}

Both of those if conditions are the same, but you'll use one or the other 
depending on context.
Apr 10 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 10 Apr 2015 23:47:19 +1000, Daniel Murphy wrote:


 "ketmar"  wrote in message news:mg8hda$2rs$12 digitalmars.com...
=20
=20

 I use arr.length when I'm working with arrays, and .empty when
 working with general ranges.  I generally prefer not to mix the two.


 isn't it a compiler task to track types? ranges can be empty, arrays
 can be empty. i can't see why one should remember that their emptiness
 if somehow different.


=20
 Nobody said you have to remember anything, it's a style choice.


ah, sorry, i thought that you mean "there is no sense to moving `.empty`,=20
'cause people should use `.length` for arrays". sorry.=
Apr 10 2015
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Friday, 10 April 2015 at 10:14:43 UTC, Martin Nowak wrote:

 On Friday, 10 April 2015 at 09:27:56 UTC, w0rp wrote:

 If we need a deprecation path, we can do it. We just warn 
 about if (arr) for a while, so you are told to use 
 if(arr.length == 0) or if (arr.ptr is null) for a while, then 
 we change the behaviour in another release.


 That's kind of the roadmap, though we'd need to wait quite a 
 while until we can reuse it.
 I've been thinking about moving std.array.empty to object. Then 
 that could more easily become the replacement idiom.

 if (arr) -> if (!arr.empty)

 It's much clearer and also what you need to write when you work 
 with ranges.


I like this. I put in a .empty property for the hashmaps and sets 
I wrote which uses .length == 0.

if (arr) is a problem for new D programmers, who will write it 
probably expecting it to be the same as if (arr.length == 0). Any 
struct type in D can behave the same way by implementing an 
overload for cast(bool).
Apr 10 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 10 April 2015 at 10:14:43 UTC, Martin Nowak wrote:

 if (arr) -> if (!arr.empty)

 It's much clearer and also what you need to write when you work 
 with ranges.


Maybe rename it "opEmpty" then.

Try to keep language protocols and library conventions separate.
May 04 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 04 May 2015 10:27:47 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Friday, 10 April 2015 at 10:14:43 UTC, Martin Nowak wrote:

 if (arr) -> if (!arr.empty)

 It's much clearer and also what you need to write when you work with
 ranges.


=20
 Maybe rename it "opEmpty" then.
=20
 Try to keep language protocols and library conventions separate.


or at least move it to "object.d", so i don't have to import "std.range"=20
to get this check working.=
May 04 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote:

 I think it's worth changing this.

 if (arr)

 translating to

 if (arr.length == 0)

 Is immediately obvious for anyone coming from at least a Python
 background. I have implemented my own hashmaps in a similar way.
 For my maps, the length is stored in the map so it can be
 retrieved in O(1) time, and cast(bool) results in map.length ==
 0. (This extends also to empty sets.)

 If we need a deprecation path, we can do it. We just warn about
 if (arr) for a while, so you are told to use if(arr.length == 0)
 or if (arr.ptr is null) for a while, then we change the behaviour
 in another release.


I agree with the change, because the current behavior is error-prone.
However, I'd just as soon leave if(arr) as illegal so that there's no
confusion over it later. Just because one set of folks think that if(arr) is
clearly equivalant to if(arr.length != 0) doesn't mean another set of folks
will - especially if it's based on what other languages are up to. For
instance, while python folks might think that it would be intuitive if
if(arr) were equivalent to if(arr.length != 0), the C folks would think that
the current behavior of it being equivalent to if(arr is null) would be more
intuitive, since they're used to thinking of arrays as pointers. By simply
forcing folks to be explicit and say if(arr.length != 0) or if(arr is null),
we avoid the problem entirely.

- Jonathan M Davis
Apr 19 2015
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:

 On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote:

 I think it's worth changing this.

 if (arr)

 translating to

 if (arr.length == 0)

 Is immediately obvious for anyone coming from at least a Python
 background. I have implemented my own hashmaps in a similar 
 way.
 For my maps, the length is stored in the map so it can be
 retrieved in O(1) time, and cast(bool) results in map.length ==
 0. (This extends also to empty sets.)

 If we need a deprecation path, we can do it. We just warn about
 if (arr) for a while, so you are told to use if(arr.length == 
 0)
 or if (arr.ptr is null) for a while, then we change the 
 behaviour
 in another release.


 I agree with the change, because the current behavior is 
 error-prone.
 However, I'd just as soon leave if(arr) as illegal so that 
 there's no
 confusion over it later. Just because one set of folks think 
 that if(arr) is
 clearly equivalant to if(arr.length != 0) doesn't mean another 
 set of folks
 will - especially if it's based on what other languages are up 
 to. For
 instance, while python folks might think that it would be 
 intuitive if
 if(arr) were equivalent to if(arr.length != 0), the C folks 
 would think that
 the current behavior of it being equivalent to if(arr is null) 
 would be more
 intuitive, since they're used to thinking of arrays as 
 pointers. By simply
 forcing folks to be explicit and say if(arr.length != 0) or 
 if(arr is null),
 we avoid the problem entirely.

 - Jonathan M Davis


Unfortunately it also disables this very useful idiom:

if(auto name = getName())

I.e. declaration and conditional in one.
Apr 19 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:

 the C folks would think that
 the current behavior of it being equivalent to if(arr is null) 
 would be more
 intuitive, since they're used to thinking of arrays as pointers.


Are they used to disregard value types too? I don't see it 
working in C: http://ideone.com/rzSSlx
Apr 20 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/20/15 12:14 PM, Kagamin wrote:

 On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:

 the C folks would think that
 the current behavior of it being equivalent to if(arr is null) would
 be more
 intuitive, since they're used to thinking of arrays as pointers.


 Are they used to disregard value types too? I don't see it working in C:
 http://ideone.com/rzSSlx


Not exactly. Because C arrays are pointers, it does work that way:

void foo(int c[])
{
    if(c) {...} // same as if(c is null)
}

But C doesn't have any other possible piece to check, as the length of 
the array is not part of the code.

The closest equivalent is C++ vectors, and if(someVector) doesn't work.

-Steve
Apr 20 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 20, 2015 16:14:39 Kagamin via Digitalmars-d wrote:

 On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:

 the C folks would think that
 the current behavior of it being equivalent to if(arr is null)
 would be more
 intuitive, since they're used to thinking of arrays as pointers.


 Are they used to disregard value types too? I don't see it
 working in C: http://ideone.com/rzSSlx


An array in C is a pointer, not a struct. So, the obvious thing for a C
programmer when they see

if(arr)

would be to think that it was equivalent to

if(arr != NULL)

or

if(arr != 0)

and _not_ something like

if(arr.length != 0)

particularly since arrays don't even know their length in C. Obviously, if
they're dealing with a struct, then it's not the same, and D arrays are
technically structs, but regardless, if you're a C/C++ programmer and you're
using a struct to hold the length of your array along with its pointer, and
you were going to decide what

if(arr)

is going to mean, then checking whether ptr was null or not would be the
obvious thing (which _can_ be defined in C++ via an overloaded cast
operator, just not in C). As such, being derived from C, D's current
behavior is very logical - _far_ more so than checking the array's length.
For someone with a C/C++ background, there's no reason whatsoever to expect
that it would be checking for length. The problem comes in when you consider
that in most other cases, D tries to avoid segfaulting for null arrays, and
treats null arrays as empty (e.g. with equality), so checking for null
arrays becomes a rare thing to need, and folks from some other languages
apparently think that it's normal to expect that

if(arr)

would check for non-empty. So, it arguably becomes too confusing to allow

if(arr)

But given D's C heritage, what it currently does is exactly what I'd expect
it to do and is likely what most C/C++ programmers would expect it to do.

- Jonathan M Davis
Apr 20 2015
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 20 April 2015 at 18:01:20 UTC, Jonathan M Davis wrote:

 An array in C is a pointer, not a struct.


True. I only question the claim that they don't care about such 
things.
Also difference between pointer and reference types seems to be 
no problem for STL string. If it wasn't designed by C 
programmers, then by whom?


 So, the obvious thing for a C programmer when they see

 if(arr)

 would be to think that it was equivalent to

 if(arr != NULL)


Don't you contradict yourself now?
arr!=null is equivalent to arr.length!=0


 D tries to avoid segfaulting for null arrays


In fact nothing like that ever happened. Bug 14436 exists because 
there was never any special treatment for null slices.
Apr 22 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, April 22, 2015 10:19:01 Kagamin via Digitalmars-d wrote:

 On Monday, 20 April 2015 at 18:01:20 UTC, Jonathan M Davis wrote:

 An array in C is a pointer, not a struct.


 True. I only question the claim that they don't care about such
 things.
 Also difference between pointer and reference types seems to be
 no problem for STL string. If it wasn't designed by C
 programmers, then by whom?


 So, the obvious thing for a C programmer when they see

 if(arr)

 would be to think that it was equivalent to

 if(arr != NULL)


 Don't you contradict yourself now?
 arr!=null is equivalent to arr.length!=0


Um. No. In C, arr != NULL, and arr.length are completely different. If you
wanted to check the length, you'd either have to have a separate length
variable or being operating on a zero-terminated string and use strlen. And
arr != NULL isn't legal D, so I would have thought that it would be clear
that I meant C code with that line.


 D tries to avoid segfaulting for null arrays


 In fact nothing like that ever happened. Bug 14436 exists because
 there was never any special treatment for null slices.


D arrays were designed in a way that they avoid segfaults; otherwise an
empty array and a null array would not be considered equal, and doing stuff
like trying to append to a null array would segfault. You have to work at it
to get a segfault with D arrays. That doesn't mean that the optimizer does
the best job (as evidenced by 14436), but D arrays are quite clearly
designed in a manner that avoids segfaults and conflates null with empty as
a result.

- Jonathan M Davis
Apr 22 2015
next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 22 April 2015 at 10:36:04 UTC, Jonathan M Davis 
wrote:

 So, the obvious thing for a C programmer when they see

 if(arr)

 would be to think that it was equivalent to

 if(arr != NULL)


 Don't you contradict yourself now?
 arr!=null is equivalent to arr.length!=0


 that I meant C code with that line.


If C programmers won't apply C intuition in D code, then there's 
no problem?


 D arrays were designed in a way that they avoid segfaults; 
 otherwise an
 empty array and a null array would not be considered equal, and 
 doing stuff
 like trying to append to a null array would segfault. You have 
 to work at it
 to get a segfault with D arrays.


Hmm... if D arrays allow segfaults, that means, they don't avoid 
segfaults. Empty and null arrays are considered equal because the 
array comparison algorithm iterates over their contents and 
compares elements one by one, if the loop passes all elements 
successfully, then the slices are equal. The algorithm pays no 
attention to null slices and doesn't make any precautions against 
segfaults, it looks as if it assumes that slices are even 
non-empty.


 That doesn't mean that the optimizer does
 the best job (as evidenced by 14436), but D arrays are quite 
 clearly
 designed in a manner that avoids segfaults and conflates null 
 with empty as a result.


14436 is a direct consequence of absence of any special treatment 
of null slices, no special attention was ever paid to null 
slices, no avoidance of segfaults in any way ever existed in the 
code. That's a total misconception.
Apr 23 2015
prev sibling parent "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 22 April 2015 at 10:36:04 UTC, Jonathan M Davis 
wrote:

 D arrays were designed in a way that they avoid segfaults; 
 otherwise an
 empty array and a null array would not be considered equal, and 
 doing stuff
 like trying to append to a null array would segfault. You have 
 to work at it
 to get a segfault with D arrays. That doesn't mean that the 
 optimizer does
 the best job (as evidenced by 14436), but D arrays are quite 
 clearly
 designed in a manner that avoids segfaults and conflates null 
 with empty as
 a result.

 - Jonathan M Davis


This is one of my favourite features of D. I've seen so many 
problems in Java where someone passes null instead of an 
ArrayList to a method and it throws a NullPointerException. I 
love that I can just use foreach on a null slice, or check its 
length, and not care if it's null most of the time. (But still 
check if it's null if I really, really care.)
Apr 23 2015
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer 
wrote:

 A confusing and dangerous "feature" of D was to treat the 
 expression if(arr) as meaning if(arr.ptr).

 Anyone coming from any number of other languages may think that 
 if(arr) means "if arr has any elements". Typically one cares 
 what is inside an array, not where it lives.

 However, while checking to see if an array has elements is very 
 similar to checking for a null pointer (obviously, a null 
 pointer array should have no elements), it's not equivalent. 
 Therefore, when attempting to fix this confusion, we had to 
 disable the if(arr) check altogether. You must now specify what 
 part of the array you care about, if(arr.ptr) or if(arr.length).

 As usual with changes of this nature, there are differing 
 opinions, and differing styles. I personally never use null as 
 a special value for an array, but others do. They use if(arr) 
 to actually mean if(arr.ptr). For these cases, the update will 
 cause some amount of busywork changing these checks.

 But when updating Phobos to comply with this change, we found 
 several actual incorrect usages. So I think the change is worth 
 it, and not much busywork. YMMV.

 What do you think?

 references:

 https://issues.dlang.org/show_bug.cgi?id=4733
 https://github.com/D-Programming-Language/dmd/pull/2885
 https://github.com/D-Programming-Language/tools/pull/166

 -Steve


As others have mentioned, why not make if(arr) be equivalent to 
if(arr.length)? It seems that's what everyone actually wants when 
they type it.
Apr 10 2015
next sibling parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Fri, 10 Apr 2015 09:35:43 +0000
John Colvin via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer 
 wrote:

 A confusing and dangerous "feature" of D was to treat the 
 expression if(arr) as meaning if(arr.ptr).

 Anyone coming from any number of other languages may think that 
 if(arr) means "if arr has any elements". Typically one cares 
 what is inside an array, not where it lives.

 However, while checking to see if an array has elements is very 
 similar to checking for a null pointer (obviously, a null 
 pointer array should have no elements), it's not equivalent. 
 Therefore, when attempting to fix this confusion, we had to 
 disable the if(arr) check altogether. You must now specify what 
 part of the array you care about, if(arr.ptr) or if(arr.length).

 As usual with changes of this nature, there are differing 
 opinions, and differing styles. I personally never use null as 
 a special value for an array, but others do. They use if(arr) 
 to actually mean if(arr.ptr). For these cases, the update will 
 cause some amount of busywork changing these checks.

 But when updating Phobos to comply with this change, we found 
 several actual incorrect usages. So I think the change is worth 
 it, and not much busywork. YMMV.

 What do you think?

 references:

 https://issues.dlang.org/show_bug.cgi?id=4733
 https://github.com/D-Programming-Language/dmd/pull/2885
 https://github.com/D-Programming-Language/tools/pull/166

 -Steve


 
 As others have mentioned, why not make if(arr) be equivalent to 
 if(arr.length)? It seems that's what everyone actually wants when 
 they type it.


Change semantic is not good idea at all
Apr 10 2015
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 10 April 2015 at 09:35:44 UTC, John Colvin wrote:

 As others have mentioned, why not make if(arr) be equivalent to 
 if(arr.length)? It seems that's what everyone actually wants 
 when they type it.


Maybe after we kept if(arr) an error for some time.

causes only problems and nothing else. D has a particularly 
fitting slice design to get it right too.
Apr 10 2015
prev sibling next sibling parent reply "jkpl" <jkpl nowhere.fr> writes:
On Friday, 10 April 2015 at 09:35:44 UTC, John Colvin wrote:

 On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer 
 wrote:

 A confusing and dangerous "feature" of D was to treat the 
 expression if(arr) as meaning if(arr.ptr).

 Anyone coming from any number of other languages may think 
 that if(arr) means "if arr has any elements". Typically one 
 cares what is inside an array, not where it lives.

 However, while checking to see if an array has elements is 
 very similar to checking for a null pointer (obviously, a null 
 pointer array should have no elements), it's not equivalent. 
 Therefore, when attempting to fix this confusion, we had to 
 disable the if(arr) check altogether. You must now specify 
 what part of the array you care about, if(arr.ptr) or 
 if(arr.length).

 As usual with changes of this nature, there are differing 
 opinions, and differing styles. I personally never use null as 
 a special value for an array, but others do. They use if(arr) 
 to actually mean if(arr.ptr). For these cases, the update will 
 cause some amount of busywork changing these checks.

 But when updating Phobos to comply with this change, we found 
 several actual incorrect usages. So I think the change is 
 worth it, and not much busywork. YMMV.

 What do you think?

 references:

 https://issues.dlang.org/show_bug.cgi?id=4733
 https://github.com/D-Programming-Language/dmd/pull/2885
 https://github.com/D-Programming-Language/tools/pull/166

 -Steve


 As others have mentioned, why not make if(arr) be equivalent to 
 if(arr.length)? It seems that's what everyone actually wants 
 when they type it.


This is not a good idea.

People who writed `if(arr)` were misunderstanding the thing. In 
every other parts of the language `if(x)` only works for pointers 
and types implicitely convertibles to bool (and other expressions 
returning such things...).

They were wrong and their error must not be accepted. An array is 
more or less like a struct and (POD) structs are never null (i 
exclude the structs with an alias this from the statement).

Then, imagine that the syntactic shortcut is accepted, this would 
lead to the following confusion:
---
char[] * arr;
if(arr)
---
Here the test is really about the array being null or not.

It's like in the topic from yesterday:

---
void a(uint p, string a = null){}
---

Totally wrong, the guy should write:

---
void a(uint p, string a = ""){}
---

because if you pass a struct as param, the param is never null !

I'm against the shortcut...it doesn't help to understand how it 
works. It's a useless and confusing shortcut. Warning about the 
amibuous usage was the right
to do.
Apr 10 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 10 April 2015 at 10:09:18 UTC, jkpl wrote:

 Then, imagine that the syntactic shortcut is accepted, this 
 would lead to the following confusion:
 ---
 char[] * arr;
 if(arr)
 ---
 Here the test is really about the array being null or not.


`arr` is a pointer, not an array. I don't understand what you're 
arguing here.


 It's like in the topic from yesterday:

 ---
 void a(uint p, string a = null){}
 ---

 Totally wrong, the guy should write:

 ---
 void a(uint p, string a = ""){}
 ---


I don't know what that topic was about, but there is nothing 
obviously wrong with either version. The language mostly treats 
both the same way:

     string nullstr = null;
     assert(nullstr == "");
     assert(nullstr.length == 0);

The only difference is that "" has a non-null address:

     assert(!nullstr.ptr);
     assert("".ptr);

OTOH, maybe the programmer in question actually wants to make a 
distinction between the two, and there's nothing wrong with doing 
that either.


 because if you pass a struct as param, the param is never null !


So what? An array isn't a struct.


 I'm against the shortcut...it doesn't help to understand how it 
 works. It's a useless and confusing shortcut. Warning about the 
 amibuous usage was the right
 to do.


I don't think it's confusing. Also note that the shortcut (=> 
length) is much more likely to be correct. There are lots of 
non-null empty arrays, but I don't know a non-contrived way to 
accidentally end up with a non-empty null array.
Apr 10 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 1:39 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 On Friday, 10 April 2015 at 10:09:18 UTC, jkpl wrote:

 Then, imagine that the syntactic shortcut is accepted, this would lead
 to the following confusion:
 ---
 char[] * arr;
 if(arr)
 ---
 Here the test is really about the array being null or not.


 `arr` is a pointer, not an array. I don't understand what you're arguing
 here.


 It's like in the topic from yesterday:

 ---
 void a(uint p, string a = null){}
 ---

 Totally wrong, the guy should write:

 ---
 void a(uint p, string a = ""){}
 ---


 I don't know what that topic was about, but there is nothing obviously
 wrong with either version. The language mostly treats both the same way:

      string nullstr = null;
      assert(nullstr == "");
      assert(nullstr.length == 0);

 The only difference is that "" has a non-null address:

      assert(!nullstr.ptr);
      assert("".ptr);

 OTOH, maybe the programmer in question actually wants to make a
 distinction between the two, and there's nothing wrong with doing that
 either.


 because if you pass a struct as param, the param is never null !


 So what? An array isn't a struct.


 I'm against the shortcut...it doesn't help to understand how it works.
 It's a useless and confusing shortcut. Warning about the amibuous
 usage was the right
 to do.


 I don't think it's confusing. Also note that the shortcut (=> length) is
 much more likely to be correct. There are lots of non-null empty arrays,
 but I don't know a non-contrived way to accidentally end up with a
 non-empty null array.


I know of one place that has a non-empty null array, TypeInfo.init():

import std.stdio;

struct S
{
     int x;
}

void main()
{
     auto x = typeid(S).init();
     writeln(x.ptr, " ", x.length);
}

output:
null 4

The reason for this is, the compiler is telling you the size is 4 bytes, 
but they should all be 0 (no need to store 0 bytes in data segment).

But this is NOT a usual situation.

-Steve
Apr 10 2015
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"John Colvin"  wrote in message news:vhujlbdtjodfvrmwckrl forum.dlang.org...


 As others have mentioned, why not make if(arr) be equivalent to 
 if(arr.length)? It seems that's what everyone actually wants when they 
 type it.


That's the long term idea, but an immediate change would break code.
Apr 10 2015
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 5:35 AM, John Colvin wrote:

 As others have mentioned, why not make if(arr) be equivalent to
 if(arr.length)? It seems that's what everyone actually wants when they
 type it.


Some code legitimately uses if(arr) to check the pointer (see link to 
the tools change that I posted originally). This code would compile, but 
silently change semantic. Such breaking changes are the worst kind, and 
should not be allowed.

In all honesty, I don't really care if we ever reintroduce if(arr) 
again, typing if(arr.length) is not that bad, and clarifies the intent.

-Steve
Apr 10 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 10 April 2015 at 09:35:44 UTC, John Colvin wrote:

 As others have mentioned, why not make if(arr) be equivalent to 
 if(arr.length)? It seems that's what everyone actually wants 
 when they type it.


Yes, and the worst part of it all, is that it mostly works, so 
you may miss it when testing.
Apr 10 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer 
wrote:

 What do you think?


Well, that's a pretty one-sided description of the argument!

I would like to invite anyone interested in this proposal to try 
compiling their own code with the latest compiler, and see how 
much busywork this creates vs. how much real bugs this identifies.

The tools repository is occasionally used as a guinea pig for 
breaking changes. Consider the amount of changes needed here, as 
an example:

https://github.com/D-Programming-Language/tools/pull/166/files

(Disclaimer: part of this is my own code, and I consider the 
distinction between null and empty arrays an obvious and useful 
principle.)

IMHO, this is not something worth breaking the language over.
Apr 10 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 10 April 2015 at 11:39:59 UTC, Vladimir Panteleev 
wrote:

 https://github.com/D-Programming-Language/tools/pull/166/files
 I don't know the code well enough to know if arr != null would 
 be more appropriate.


It's probably a nitpick, I like arr!=null expression a lot, but 
currently compiler generates a horrible code for it: ldc 
generates comparison with typeinfos, and dmd inlines whole memcmp 
among other things instead of converting it to just arr.length!=0.
Apr 10 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Kagamin"  wrote in message news:pdxfmrxrtfcwextsankd forum.dlang.org...


 It's probably a nitpick, I like arr!=null expression a lot, but currently 
 compiler generates a horrible code for it: ldc generates comparison with 
 typeinfos, and dmd inlines whole memcmp among other things instead of 
 converting it to just arr.length!=0.


Things like this are worth reporting. 
https://issues.dlang.org/show_bug.cgi?id=14436
Apr 10 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 10 April 2015 at 11:59:32 UTC, Kagamin wrote:

 On Friday, 10 April 2015 at 11:39:59 UTC, Vladimir Panteleev 
 wrote:

 https://github.com/D-Programming-Language/tools/pull/166/files
 I don't know the code well enough to know if arr != null would 
 be more appropriate.


 It's probably a nitpick, I like arr!=null expression a lot, but 
 currently compiler generates a horrible code for it: ldc 
 generates comparison with typeinfos, and dmd inlines whole 
 memcmp among other things instead of converting it to just 
 arr.length!=0.


gcc does what you want:

bool foo(int[] a)
{
   return a != null;
}

bool bar(int[] a)
{
   return a.length != 0;
}

bool example.foo(int[]):
	testq	%rdi, %rdi
	setne	%al
	ret
bool example.bar(int[]):
	testq	%rdi, %rdi
	setne	%al
	ret
Apr 10 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 10 April 2015 at 17:37:03 UTC, John Colvin wrote:

 On Friday, 10 April 2015 at 11:59:32 UTC, Kagamin wrote:

 On Friday, 10 April 2015 at 11:39:59 UTC, Vladimir Panteleev 
 wrote:

 https://github.com/D-Programming-Language/tools/pull/166/files
 I don't know the code well enough to know if arr != null 
 would be more appropriate.


 It's probably a nitpick, I like arr!=null expression a lot, 
 but currently compiler generates a horrible code for it: ldc 
 generates comparison with typeinfos, and dmd inlines whole 
 memcmp among other things instead of converting it to just 
 arr.length!=0.


 gcc does what you want:

 bool foo(int[] a)
 {
   return a != null;
 }

 bool bar(int[] a)
 {
   return a.length != 0;
 }

 bool example.foo(int[]):
 	testq	%rdi, %rdi
 	setne	%al
 	ret
 bool example.bar(int[]):
 	testq	%rdi, %rdi
 	setne	%al
 	ret


Whoops, that should be gdc, not gcc
Apr 10 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 7:39 AM, Vladimir Panteleev wrote:

 On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer wrote:

 What do you think?


 Well, that's a pretty one-sided description of the argument!


So, what's the other side? :) I'm only on one side of the argument, I 
don't want to misrepresent your side.


 The tools repository is occasionally used as a guinea pig for breaking
 changes. Consider the amount of changes needed here, as an example:

 https://github.com/D-Programming-Language/tools/pull/166/files


I did include this link in my OP. I wasn't trying to hide anything.

Frankly, that list of changes is quite small (40 lines). We already have 
another poster who had to change 1000 lines, and most of them were 
incorrect before the change.

-Steve
Apr 10 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 09 Apr 2015 16:59:00 -0400, Steven Schveighoffer wrote:


 A confusing and dangerous "feature" of D was to treat the expression
 if(arr) as meaning if(arr.ptr).
=20
 Anyone coming from any number of other languages may think that if(arr)
 means "if arr has any elements". Typically one cares what is inside an
 array, not where it lives.
=20
 However, while checking to see if an array has elements is very similar
 to checking for a null pointer (obviously, a null pointer array should
 have no elements), it's not equivalent. Therefore, when attempting to
 fix this confusion, we had to disable the if(arr) check altogether. You
 must now specify what part of the array you care about, if(arr.ptr) or
 if(arr.length).
=20
 As usual with changes of this nature, there are differing opinions, and
 differing styles. I personally never use null as a special value for an
 array, but others do. They use if(arr) to actually mean if(arr.ptr). For
 these cases, the update will cause some amount of busywork changing
 these checks.
=20
 But when updating Phobos to comply with this change, we found several
 actual incorrect usages. So I think the change is worth it, and not much
 busywork. YMMV.
=20
 What do you think?


this is good, as `if (arr.ptr)` is really confusing. yet i can't=20
understand why don't rewrite it to `if (arr.length)` instead.=
Apr 10 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 10 Apr 2015 12:53:43 +0000, ketmar wrote:


 this is good, as `if (arr.ptr)` is really confusing. yet i can't
 understand why don't rewrite it to `if (arr.length)` instead.
Apr 10 2015
prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Interesting trivia, I even found this bug in the documentation of the
first dmd release http://downloads.dlang.org/releases/0.x/0.100/dmd.100.zip.


Checking For Empty Strings

C++ strings use a function to determine if a string is empty:
	string str;
	if (str.empty())
		// string is empty
In D, an empty string is just null:
	char[] str;
	if (!str)
		// string is empty


Apparently it was later fixed to if (!str.length)
http://www.digitalmars.com/d/1.0/cppstrings.html.
Apr 22 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/22/15 6:10 PM, Martin Nowak wrote:

 Interesting trivia, I even found this bug in the documentation of the
 first dmd release http://downloads.dlang.org/releases/0.x/0.100/dmd.100.zip.


 Checking For Empty Strings

 C++ strings use a function to determine if a string is empty:
 	string str;
 	if (str.empty())
 		// string is empty
 In D, an empty string is just null:
 	char[] str;
 	if (!str)
 		// string is empty


 Apparently it was later fixed to if (!str.length)
 http://www.digitalmars.com/d/1.0/cppstrings.html.


Ahh, if only we could go back in time and force Walter to fix the 
compiler instead of the docs ;)

-Steve
Apr 23 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
FYI, Andrei and Walter are reversing this change barring any new 
evidence it's helpful to people. Please speak up if you disagree.

https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912

-Steve
Apr 28 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/28/15 9:38 PM, Steven Schveighoffer wrote:

 FYI, Andrei and Walter are reversing this change barring any new
 evidence it's helpful to people. Please speak up if you disagree.

 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912


We shouldn't frame it as black and white. It has usefulness, it also has 
drawbacks. My thesis is the drawbacks overwhelm the usefulness. -- Andrei
Apr 28 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/29/15 1:14 AM, Andrei Alexandrescu wrote:

 On 4/28/15 9:38 PM, Steven Schveighoffer wrote:

 FYI, Andrei and Walter are reversing this change barring any new
 evidence it's helpful to people. Please speak up if you disagree.

 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912


 We shouldn't frame it as black and white. It has usefulness, it also has
 drawbacks. My thesis is the drawbacks overwhelm the usefulness. -- Andrei


I'm not. This is an RFP to answer your call for more evidence.

-Steve
Apr 28 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/28/15 11:03 PM, Steven Schveighoffer wrote:

 On 4/29/15 1:14 AM, Andrei Alexandrescu wrote:

 On 4/28/15 9:38 PM, Steven Schveighoffer wrote:

 FYI, Andrei and Walter are reversing this change barring any new
 evidence it's helpful to people. Please speak up if you disagree.

 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912


 We shouldn't frame it as black and white. It has usefulness, it also has
 drawbacks. My thesis is the drawbacks overwhelm the usefulness. -- Andrei


 I'm not. This is an RFP to answer your call for more evidence.


Ah, right. I misread, apologies. -- Andrei
Apr 29 2015
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:


 FYI, Andrei and Walter are reversing this change barring any 
 new evidence it's helpful to people. Please speak up if you 
 disagree.


There's no more evidence. It's an improvement, for people coming 
from Python. The current semantics is not meaningful. One of the 
points of D over C++ was to fix irrationally designed parts, like 
this small problem. Many small design mistakes like this one 
create C++ we know and hate. We should fix such small problems 
quickly and look forward, instead of debating forever and 
reverting every small step forward like this. My presence around 
here is becoming useless.

Bye,
bearophile
Apr 29 2015
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29 April 2015 at 06:38, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 FYI, Andrei and Walter are reversing this change barring any new evidence
 it's helpful to people. Please speak up if you disagree.

 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912

 -Steve


I disagree, and I would extend my thoughts to say that I don't think
that the change is enough.  We should also be warning on delegates and
associative arrays too!

if (arr)  // Implicitly converted to (arr.ptr | arr.length) != 0
if (dg)  // Implicitly converted to (dg.ptr | dg.funcptr) != 0
if (aa)  // Implicitly converted to (aa.ptr != null)

Iain
Apr 29 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/29/15 4:29 AM, Iain Buclaw via Digitalmars-d wrote:

 On 29 April 2015 at 06:38, Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 FYI, Andrei and Walter are reversing this change barring any new evidence
 it's helpful to people. Please speak up if you disagree.

 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912


 I disagree, and I would extend my thoughts to say that I don't think
 that the change is enough.  We should also be warning on delegates and
 associative arrays too!

 if (arr)  // Implicitly converted to (arr.ptr | arr.length) != 0


if(arr) simply means if(arr.ptr) != 0. Length does not come into play.


 if (dg)  // Implicitly converted to (dg.ptr | dg.funcptr) != 0


I don't know if I've ever expected that, you sure that's true? I would 
actually expect if(dg) to be equivalent to if(dg.funcptr). I have no 
idea how a dg would have a null pointer but valid funcptr.


 if (aa)  // Implicitly converted to (aa.ptr != null)


This is easily fixed when we fix aa to be a library type. We don't need 
compiler help to fix this issue (we do need compiler help to remove AA 
specialty code from the compiler, but once it's out, we can fix this 
without effort).

-Steve
Apr 29 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/29/15 10:41 PM, Steven Schveighoffer wrote:

 On 4/29/15 4:29 AM, Iain Buclaw via Digitalmars-d wrote:



 if (dg)  // Implicitly converted to (dg.ptr | dg.funcptr) != 0


 I don't know if I've ever expected that, you sure that's true? I would
 actually expect if(dg) to be equivalent to if(dg.funcptr). I have no
 idea how a dg would have a null pointer but valid funcptr.


reverse that, I don't know how a dg would have a null funcptr but valid ptr.


 if (aa)  // Implicitly converted to (aa.ptr != null)


 This is easily fixed when we fix aa to be a library type. We don't need
 compiler help to fix this issue (we do need compiler help to remove AA
 specialty code from the compiler, but once it's out, we can fix this
 without effort).


Hah! without *compiler* effort :)

-Steve
Apr 29 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 April 2015 at 04:41, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 4/29/15 4:29 AM, Iain Buclaw via Digitalmars-d wrote:

 On 29 April 2015 at 06:38, Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 FYI, Andrei and Walter are reversing this change barring any new evidence
 it's helpful to people. Please speak up if you disagree.


 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912


 I disagree, and I would extend my thoughts to say that I don't think
 that the change is enough.  We should also be warning on delegates and
 associative arrays too!

 if (arr)  // Implicitly converted to (arr.ptr | arr.length) != 0


 if(arr) simply means if(arr.ptr) != 0. Length does not come into play.


https://github.com/D-Programming-Language/dlang.org/pull/981#commitcomment-10918439

The two mov's followed by an 'or' suspiciously look like (.ptr | .length) to me.


 if (dg)  // Implicitly converted to (dg.ptr | dg.funcptr) != 0



 I don't know if I've ever expected that, you sure that's true? I would
 actually expect if(dg) to be equivalent to if(dg.funcptr). I have no idea
 how a dg would have a null pointer but valid funcptr.


Yes, it does (it emits the same assembly as arrays).


 if (aa)  // Implicitly converted to (aa.ptr != null)



 This is easily fixed when we fix aa to be a library type. We don't need
 compiler help to fix this issue (we do need compiler help to remove AA
 specialty code from the compiler, but once it's out, we can fix this without
 effort).


It's still annoying to have to special-case non-scalar types in
boolean contexts.  The front-end should do this lowering. :-)

https://github.com/D-Programming-GDC/GDC/blob/e9bfc0332e42d01402aeb2063d38fc5ea4e12fea/gcc/d/d-codegen.cc#L605

Iain.
Apr 29 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/29/15 11:14 PM, Iain Buclaw via Digitalmars-d wrote:

 On 30 April 2015 at 04:41, Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 4/29/15 4:29 AM, Iain Buclaw via Digitalmars-d wrote:

 On 29 April 2015 at 06:38, Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 FYI, Andrei and Walter are reversing this change barring any new evidence
 it's helpful to people. Please speak up if you disagree.


 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912


 I disagree, and I would extend my thoughts to say that I don't think
 that the change is enough.  We should also be warning on delegates and
 associative arrays too!

 if (arr)  // Implicitly converted to (arr.ptr | arr.length) != 0


 if(arr) simply means if(arr.ptr) != 0. Length does not come into play.


 https://github.com/D-Programming-Language/dlang.org/pull/981#commitcomment-10918439

 The two mov's followed by an 'or' suspiciously look like (.ptr | .length) to
me.


Huh. I guess you are right. I never thought to test that, but it does 
indeed mean that.

I suppose for all intents and purposes, arrays with nonzero length and 
null pointer are so rare it may as well just be testing if the pointer 
is non-null.


 if (dg)  // Implicitly converted to (dg.ptr | dg.funcptr) != 0



 I don't know if I've ever expected that, you sure that's true? I would
 actually expect if(dg) to be equivalent to if(dg.funcptr). I have no idea
 how a dg would have a null pointer but valid funcptr.


 Yes, it does (it emits the same assembly as arrays).


OK, but in this case I think dg.funcptr is what we want to test, the 
dg.ptr isn't really relevant. And I don't think you'd find a case where 
dg.funcptr is null but dg.ptr isn't.


 if (aa)  // Implicitly converted to (aa.ptr != null)



 This is easily fixed when we fix aa to be a library type. We don't need
 compiler help to fix this issue (we do need compiler help to remove AA
 specialty code from the compiler, but once it's out, we can fix this without
 effort).


 It's still annoying to have to special-case non-scalar types in
 boolean contexts.  The front-end should do this lowering. :-)


None of these things really affect me, I never use if(arr) or if(aa), 
because I'm too skeptical of what they convey, and have been burned by 
those in the past. And if(dg) doesn't seem to have issues with how it's 
implemented.

If it was in a code review, I'd reject such usages.

I personally don't think if(arr) or if(aa) should EVER compile with any 
kind of lowering. The meaning is too non-obvious.

-Steve
May 02 2015
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 29 April 2015 at 04:38:12 UTC, Steven Schveighoffer 
wrote:

 FYI, Andrei and Walter are reversing this change barring any 
 new evidence it's helpful to people. Please speak up if you 
 disagree.

 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912


I disagree, too. For me, the value of this change is not in 
detecting bugs, but in cleaning up a design mistake. It therefore 
doesn't matter whether there is evidence it helps avoiding bugs.

However, I did find several ones in my own code and in vibe.d:

https://github.com/rejectedsoftware/vibe.d/commit/e9e66f4e726db64d15e078dc472606b57783728a#diff-a0c0675933703d01a5d6ad8ebfc097abL79
https://github.com/D-Programming-Language/dub/pull/556/files

and similar ones with assert().
Apr 29 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 29 April 2015 at 11:07:52 UTC, Marc Schütz wrote:
://github.com/rejectedsoftware/vibe.d/commit/e9e66f4e726db64d15e078dc472606b57783728a#diff-a0c0675933703d01a5d6ad8ebfc097abL79

Are you talking about the last diff in particular? Because I 
would argue that that one is a poor design decision in Vibe 
(overloaded functions' return values should have the same 
semantics). What if one overload returned "bool" for 
success/failure and another a "size_t" for number of characters 
written to the error message buffer?


 https://github.com/D-Programming-Language/dub/pull/556/files


Forbidding arrays for assert and enforce conditions sounds like a 
good idea.
Apr 29 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 29 April 2015 at 11:28:02 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 29 April 2015 at 11:07:52 UTC, Marc Schütz wrote:
 ://github.com/rejectedsoftware/vibe.d/commit/e9e66f4e726db64d15e078dc472606b57783728a#diff-a0c0675933703d01a5d6ad8ebfc097abL79

 Are you talking about the last diff in particular? Because I 
 would argue that that one is a poor design decision in Vibe 
 (overloaded functions' return values should have the same 
 semantics). What if one overload returned "bool" for 
 success/failure and another a "size_t" for number of characters 
 written to the error message buffer?


You're probably right, it's not the best design. But still, the 
original version compiled fine because that string was implicitly 
convertible to bool, which the DMD change caught.
Apr 29 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/29/15 7:05 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 On Wednesday, 29 April 2015 at 11:28:02 UTC, Vladimir Panteleev wrote:

 On Wednesday, 29 April 2015 at 11:07:52 UTC, Marc Schütz wrote:
 ://github.com/rejectedsoftware/vibe.d/commit/e9e66f4e726db64d15e078dc472606b57783728a#diff-a0c0675933703d01a5d6ad8ebfc097abL79


 Are you talking about the last diff in particular? Because I would
 argue that that one is a poor design decision in Vibe (overloaded
 functions' return values should have the same semantics). What if one
 overload returned "bool" for success/failure and another a "size_t"
 for number of characters written to the error message buffer?


 You're probably right, it's not the best design. But still, the original
 version compiled fine because that string was implicitly convertible to
 bool, which the DMD change caught.


I have no doubt the change can find certain errors. Problem is false 
positives. FWIW these are the changes I had to operate on std.allocator 
to make it work with the new compiler. One per 194 lines on average, all 
false positives:

https://github.com/andralex/phobos/commit/4c14bf48fb5754782aec2380d41529eba3f2357b


Andrei
Apr 29 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 29 April 2015 at 17:35:58 UTC, Andrei Alexandrescu 
wrote:

 I have no doubt the change can find certain errors. Problem is 
 false positives. FWIW these are the changes I had to operate on 
 std.allocator to make it work with the new compiler. One per 
 194 lines on average, all false positives:


Yeah, but I think that it's safe to say that std.allocator is not 
the normal case, since it's operating so heavily on arrays (and 
non-GC allocated no less), and it's caring about their pointers 
rather than what they point to, whereas most D array code doesn't 
care about the ptr value of the array at all. In general, at 
most, it'll care about whether the array is empty or not. So, I 
would expect that for most programs, they won't see this warning 
much - be it a false positive or not - and if they do see it, the 
odds are pretty high that it's not a false positive. Yes, there 
will be code out there which uses if(arr) correctly, and not 
being able to do if(auto ptr = arr) will be annoying for some 
folks, but given how null and empty are so frequently conflated 
with arrays in D, I very much doubt that much code is going to be 
using if(arr) and want it to be equivalent to if(arr !is null).

Granted, we can't know for sure how common if(arr) is used in the 
wild - be it correctly or incorrectly - but std.allocator is 
definitely not your average code, and the consensus seems to be 
that if(arr) is error-prone even if it's occasionally useful.

- Jonathan M Davis
Apr 29 2015
next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/29/2015 09:15 PM, Jonathan M Davis wrote:

 Yeah, but I think that it's safe to say that std.allocator is not the
 normal case


std.allocator really isn't a general example.

I'm exclusively using if (ary.length) or if (!ary.empty) in my code to
avoid the problem.
Occasionally I'm using if (auto ary = func()), despite the fact that the
semantics are wrong, but it's nice and short and works as long a func
always returns null instead of empty slices.
But it's very fragile, hard to spot during debugging, and I already
spent too many hours on that.

So I'd expect any code analyzer to fault such usage and any D book to
teach people not to use arrays as boolean, at which point we'd be better
off to slowly remove it from the language.
Apr 29 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/29/15 8:35 PM, Martin Nowak wrote:

 Occasionally I'm using if (auto ary = func()), despite the fact that the
 semantics are wrong, but it's nice and short and works as long a func
 always returns null instead of empty slices.


I wonder if it's possible to fix this, as it is, IMO, the only 
legitimate drawback of this change. Could we make the following work?

if((auto ary = func()).length)

-Steve
Apr 29 2015
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 30 April 2015 at 02:44:22 UTC, Steven Schveighoffer 
wrote:

 On 4/29/15 8:35 PM, Martin Nowak wrote:

 Occasionally I'm using if (auto ary = func()), despite the 
 fact that the
 semantics are wrong, but it's nice and short and works as long 
 a func
 always returns null instead of empty slices.


 I wonder if it's possible to fix this, as it is, IMO, the only 
 legitimate drawback of this change. Could we make the following 
 work?

 if((auto ary = func()).length)


Another thing to consider is how this is a general problem. It's 
not that atypical to want to declare a variable in the if 
condition and then use a function call on it for the actual 
condition, which it looks like your suggestion would work with, 
but if we consider a solution like that, I think that we need to 
consider the general case and not just checking for length on 
arrays.

Another syntax might be something like

if(auto ary = func(); ary.length)

and make it similar to how for loops work. That would also allow 
you to check stuff other than what the variable gets initialized 
with or to use it in a more complicated expression. e.g.

if(auto ary = func(); foo(ary))

It's also arguably more consistent with other language features. 
But regardless, the general idea of what you're proposing could 
provide some good syntactic sugar.

- Jonathan M Davis
Apr 29 2015
prev sibling parent reply Byron Heads <byron.heads gmail.com> writes:
On Wed, 29 Apr 2015 22:44:22 -0400, Steven Schveighoffer wrote:


 On 4/29/15 8:35 PM, Martin Nowak wrote:

 Occasionally I'm using if (auto ary = func()), despite the fact that
 the semantics are wrong, but it's nice and short and works as long a
 func always returns null instead of empty slices.


 
 I wonder if it's possible to fix this, as it is, IMO, the only
 legitimate drawback of this change. Could we make the following work?
 
 if((auto ary = func()).length)
 
 -Steve




I would have though this would work:

if(auto x = foo(), !x.empty)
Apr 30 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/30/15 5:34 AM, Byron Heads wrote:

 On Wed, 29 Apr 2015 22:44:22 -0400, Steven Schveighoffer wrote:


 On 4/29/15 8:35 PM, Martin Nowak wrote:

 Occasionally I'm using if (auto ary = func()), despite the fact that
 the semantics are wrong, but it's nice and short and works as long a
 func always returns null instead of empty slices.


 I wonder if it's possible to fix this, as it is, IMO, the only
 legitimate drawback of this change. Could we make the following work?

 if((auto ary = func()).length)

 -Steve




 I would have though this would work:

 if(auto x = foo(), !x.empty)


That's because it means this:

if(auto x = (foo(), !x.empty))

which I think would be invalid since you are using x before assignment.

-Steve
May 02 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 29 April 2015 at 19:15:46 UTC, Jonathan M Davis
wrote:

 but std.allocator is definitely not your average code


OK, I'm tired of hearing this argument.

Here's the results against my ae library:

C:\Projects\ae\net\http\caching.d(97,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.uncompressedDataCache !is null,
this.uncompressedDataCache.length, or
this.uncompressedDataCache.ptr instead
C:\Projects\ae\net\http\caching.d(104,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.deflateDataCache !is null,
this.deflateDataCache.length, or this.deflateDataCache.ptr instead
C:\Projects\ae\net\http\caching.d(112,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.gzipDataCache !is null,
this.gzipDataCache.length, or this.gzipDataCache.ptr instead
C:\Projects\ae\net\http\caching.d(169,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.contentType !is null,
this.contentType.length, or this.contentType.ptr instead
C:\Projects\ae\sys\file.d(383,8): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: tmp !is null, tmp.length, or tmp.ptr instead
C:\Projects\ae\sys\file.d(971,17): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.oldPath !is null,
this.oldPath.length, or this.oldPath.ptr instead
C:\Projects\ae\sys\file.d(977,11): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.oldPath !is null,
this.oldPath.length, or this.oldPath.ptr instead
C:\Projects\ae\sys\file.d(988,6): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: dir !is null, dir.length, or dir.ptr instead
C:\Projects\ae\sys\persistence.d(142,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.fileName !is null,
this.fileName.length, or this.fileName.ptr instead
C:\Projects\ae\sys\persistence.d(157,11): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.fileName !is null,
this.fileName.length, or this.fileName.ptr instead
C:\Projects\ae\utils\xmlsel.d(84,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: tag !is null, tag.length, or tag.ptr
instead
C:\Projects\ae\utils\xmlsel.d(86,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: id !is null, id.length, or id.ptr instead
C:\Projects\ae\utils\xmlsel.d(88,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: cls !is null, cls.length, or cls.ptr
instead
C:\Projects\ae\net\http\server.d(357,4): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: vhost !is null, vhost.length, or
vhost.ptr instead
C:\Projects\ae\net\ietf\message.d(166,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: rawContent !is null, rawContent.length,
or rawContent.ptr instead
C:\Projects\ae\net\ietf\message.d(168,9): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.mimeType !is null,
this.mimeType.length, or this.mimeType.ptr instead
C:\Projects\ae\net\ietf\message.d(188,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: part.content !is null,
part.content.length, or part.content.ptr instead
C:\Projects\ae\net\ietf\message.d(188,27): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.content !is null,
this.content.length, or this.content.ptr instead
C:\Projects\ae\net\ietf\message.d(193,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.content !is null,
this.content.length, or this.content.ptr instead
C:\Projects\ae\net\ietf\message.d(354,35): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.id !is null, this.id.length, or
this.id.ptr instead
C:\Projects\ae\net\ietf\message.d(451,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.id !is null, this.id.length, or
this.id.ptr instead
C:\Projects\ae\net\http\client.d(65,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.currentRequest.data !is null,
this.currentRequest.data.length, or this.currentRequest.data.ptr
instead
C:\Projects\ae\sys\install\dmc.d(32,65): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.ver !is null, this.ver.length, or
this.ver.ptr instead
C:\Projects\ae\sys\net\curl.d(61,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: result !is null, result.length, or
result.ptr instead
C:\Projects\ae\utils\xmlbuild.d(75,29): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: (*__withSym).text !is null,
(*__withSym).text.length, or (*__withSym).text.ptr instead
C:\Projects\ae\net\irc\client.d(610,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: reason !is null, reason.length, or
reason.ptr instead
C:\Projects\ae\sys\vfs\package.d(103,17): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: getVFSName(path) !is null,
getVFSName(path).length, or getVFSName(path).ptr instead
C:\Projects\ae\utils\bench.d(46,6): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: action !is null, action.length, or
action.ptr instead
C:\Projects\ae\utils\bench.d(46,16): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: currentAction !is null,
currentAction.length, or currentAction.ptr instead
C:\Projects\ae\utils\bench.d(46,16): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: currentAction !is null,
currentAction.length, or currentAction.ptr instead
C:\Projects\ae\sys\file.d(176,7): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: dir !is null, dir.length, or dir.ptr instead
C:\Projects\ae\sys\file.d(40,13): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: pattern !is null, pattern.length, or pattern.ptr
instead
C:\Projects\ae\sys\file.d(46,27): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: pattern !is null, pattern.length, or pattern.ptr
instead
C:\Projects\ae\sys\file.d(46,27): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: pattern !is null, pattern.length, or pattern.ptr
instead
C:\Projects\ae\sys\file.d(213,7): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: dir !is null, dir.length, or dir.ptr instead
C:\Projects\ae\sys\paths.d(59,45): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: appName !is null, appName.length, or
appName.ptr instead
C:\Projects\ae\net\nntp\listener.d(60,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.lastDate !is null,
this.lastDate.length, or this.lastDate.ptr instead
C:\Projects\ae\net\dns\dnsbl.d(81,6): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: result !is null, result.length, or
result.ptr instead
C:\Projects\ae\net\dns\dnsbl.d(84,6): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: result !is null, result.length, or
result.ptr instead
C:\Projects\ae\net\irc\server.d(78,36): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.server.addressMask !is null,
this.server.addressMask.length, or this.server.addressMask.ptr
instead
C:\Projects\ae\net\irc\server.d(191,33): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: channel.modes.strings[107] !is null,
channel.modes.strings[107].length, or
channel.modes.strings[107].ptr instead
C:\Projects\ae\net\irc\server.d(254,78): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: channel.topic !is null,
channel.topic.length, or channel.topic.ptr instead
C:\Projects\ae\net\irc\server.d(292,15): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: mask !is null, mask.length, or mask.ptr
instead
C:\Projects\ae\net\irc\server.d(304,14): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: mask !is null, mask.length, or mask.ptr
instead
C:\Projects\ae\net\irc\server.d(321,37): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: mask !is null, mask.length, or mask.ptr
instead
C:\Projects\ae\net\irc\server.d(363,9): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: client.away !is null, client.away.length,
or client.away.ptr instead
C:\Projects\ae\net\irc\server.d(413,12): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.server.operPassword !is null,
this.server.operPassword.length, or this.server.operPassword.ptr
instead
C:\Projects\ae\net\irc\server.d(460,9): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.server.password !is null,
this.server.password.length, or this.server.password.ptr instead
C:\Projects\ae\net\irc\server.d(611,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: channel.topic !is null,
channel.topic.length, or channel.topic.ptr instead
C:\Projects\ae\net\irc\server.d(642,32): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: channel.modes.strings[cast(ulong)c] !is
null, channel.modes.strings[cast(ulong)c].length, or
channel.modes.strings[cast(ulong)c].ptr instead
C:\Projects\ae\net\irc\server.d(790,35): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: channel.modes.strings[cast(ulong)c] !is
null, channel.modes.strings[cast(ulong)c].length, or
channel.modes.strings[cast(ulong)c].ptr instead
C:\Projects\ae\net\irc\server.d(1041,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.network !is null,
this.network.length, or this.network.ptr instead
C:\Projects\ae\sys\log.d(34,7): Warning: implicit conversion of
dynamic arrays to bool can be ambiguous and will be deprecated.
Use one of: logDir !is null, logDir.length, or logDir.ptr instead
C:\Projects\ae\net\http\responseex.d(145,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: mimeType !is null, mimeType.length, or
mimeType.ptr instead
C:\Projects\ae\net\http\responseex.d(230,27): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: details !is null, details.length, or
details.ptr instead
C:\Projects\ae\net\http\responseex.d(241,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: location !is null, location.length, or
location.ptr instead
C:\Projects\ae\sys\windows\exception.d(55,6): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: cond !is null, cond.length, or cond.ptr
instead
C:\Projects\ae\sys\net\wininet.d(230,10): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: location !is null, location.length, or
location.ptr instead
C:\Projects\ae\sys\net\ae.d(95,10): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: result !is null, result.length, or
result.ptr instead
C:\Projects\ae\sys\d\manager.d(152,9): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.git.path !is null,
this.git.path.length, or this.git.path.ptr instead
C:\Projects\ae\sys\d\manager.d(235,9): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.git.path !is null,
this.git.path.length, or this.git.path.ptr instead
C:\Soft\dmd2d\windows\bin\..\..\src\phobos\std\exception.d(351,10):
Warning: implicit conversion of dynamic arrays to bool can be
ambiguous and will be deprecated. Use one of: value !is null,
value.length, or value.ptr instead
C:\Projects\ae\sys\d\manager.d(1090,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.config.deps.hostDC !is null,
this.config.deps.hostDC.length, or this.config.deps.hostDC.ptr
instead
C:\Projects\ae\sys\d\manager.d(1104,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.config.deps.dmcDir !is null,
this.config.deps.dmcDir.length, or this.config.deps.dmcDir.ptr
instead
C:\Projects\ae\sys\d\manager.d(1109,15): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: ver !is null, ver.length, or ver.ptr
instead
C:\Projects\ae\sys\d\manager.d(1123,8): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.config.deps.vsDir !is null,
this.config.deps.vsDir.length, or this.config.deps.vsDir.ptr
instead
C:\Projects\ae\sys\windows\exception.d(46,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: str !is null, str.length, or str.ptr
instead
C:\Projects\ae\sys\config.d(34,9): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: appName !is null, appName.length, or
appName.ptr instead
C:\Projects\ae\sys\config.d(36,8): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: companyName !is null, companyName.length,
or companyName.ptr instead
C:\Projects\ae\net\http\common.d(92,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: protocol !is null, protocol.length, or
protocol.ptr instead
C:\Soft\dmd2d\windows\bin\..\..\src\phobos\std\functional.d-mixin-119(119,1):
Warning: implicit conversion of dynamic arrays to bool can be
ambiguous and will be deprecated. Use one of: __a !is null,
__a.length, or __a.ptr instead
C:\Projects\ae\net\http\common.d(470,7): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: acceptEncoding !is null,
acceptEncoding.length, or acceptEncoding.ptr instead
C:\Projects\ae\utils\feed.d(72,7): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: link !is null, link.length, or link.ptr
instead
C:\Projects\ae\sys\d\repo.d(41,10): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.git.path !is null,
this.git.path.length, or this.git.path.ptr instead
C:\Projects\ae\sys\d\repo.d(81,8): Warning: implicit conversion
of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.currentHead !is null,
this.currentHead.length, or this.currentHead.ptr instead
C:\Projects\ae\sys\persistence.d(157,11): Warning: implicit
conversion of dynamic arrays to bool can be ambiguous and will be
deprecated. Use one of: this.fileName !is null,
this.fileName.length, or this.fileName.ptr instead

I didn't examine every single one, but the first dozen are all
false positives.

Oh, and note the few that occur in Phobos templates (with no
instantiation trace). I'll have fun tracking those down!
Apr 29 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 30 April 2015 at 02:51:33 UTC, Vladimir Panteleev 
wrote:

 OK, I'm tired of hearing this argument.


Distinction between null and empty can be done, the problem is it 
doesn't fly in mainstream.
Apr 30 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 April 2015 at 11:43:06 UTC, Kagamin wrote:

 On Thursday, 30 April 2015 at 02:51:33 UTC, Vladimir Panteleev 
 wrote:

 OK, I'm tired of hearing this argument.


 Distinction between null and empty can be done, the problem is 
 it doesn't fly in mainstream.


if (myslice is []) would wheck for null slice.
Apr 30 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:ajrysqkjmlqjlmkipboz forum.dlang.org...


 On Wednesday, 29 April 2015 at 19:15:46 UTC, Jonathan M Davis
 wrote:

 but std.allocator is definitely not your average code


 OK, I'm tired of hearing this argument.


It's valid though.  Most array code cares more about the contents than the 
address, while std.allocator only cares about the address.


 Here's the results against my ae library:


...

 I didn't examine every single one, but the first dozen are all
 false positives.


Yeah, looks like you're intentionally checking for null rather than empty. 
It sucks that so many places need updating.


 Oh, and note the few that occur in Phobos templates (with no
 instantiation trace). I'll have fun tracking those down!


Is that from string lambdas?  Does it give an instantiation trace when you 
use it with warning as errors?
Apr 30 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 30 April 2015 at 11:46:05 UTC, Daniel Murphy wrote:

 Is that from string lambdas?


I don't know. The one in std.exception is probably due to an 
array being used as a condition for enforce.


 Does it give an instantiation trace when you use it with 
 warning as errors?


It doesn't.
Apr 30 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:swjdkyjsurpjdqrvqonq forum.dlang.org...


 I don't know. The one in std.exception is probably due to an array being 
 used as a condition for enforce.


Yep, that's not nice.  From what I can see the warning in the template 
constraint is ignored, and so the call succeeds.  I don't know how to force 
a failure there with a warning.
Apr 30 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/15 4:46 AM, Daniel Murphy wrote:

 "Vladimir Panteleev"  wrote in message
 news:ajrysqkjmlqjlmkipboz forum.dlang.org...


 On Wednesday, 29 April 2015 at 19:15:46 UTC, Jonathan M Davis
 wrote:

 but std.allocator is definitely not your average code


 OK, I'm tired of hearing this argument.


 It's valid though.


I think we need to stop here. I'll make the PR today for reverting this 
language change. We can't handle D like a semester science project, 
because for as long as we do we won't have credibility.

This trickle of teeny-bit breaking changes for the sake of touted 
benefits must stop.

In the future please do not make breaking changes without my and 
Walter's approval.


Thanks,

Andrei
Apr 30 2015
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 April 2015 at 17:08, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 4/30/15 4:46 AM, Daniel Murphy wrote:

 "Vladimir Panteleev"  wrote in message
 news:ajrysqkjmlqjlmkipboz forum.dlang.org...


 On Wednesday, 29 April 2015 at 19:15:46 UTC, Jonathan M Davis
 wrote:

 but std.allocator is definitely not your average code


 OK, I'm tired of hearing this argument.



 It's valid though.



 I think we need to stop here. I'll make the PR today for reverting this
 language change. We can't handle D like a semester science project, because
 for as long as we do we won't have credibility.

 This trickle of teeny-bit breaking changes for the sake of touted benefits
 must stop.

 In the future please do not make breaking changes without my and Walter's
 approval.


At least enforce a behaviour in the frontend if you are going to revert.
Apr 30 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/15 8:51 AM, Iain Buclaw via Digitalmars-d wrote:

 At least enforce a behaviour in the frontend if you are going to revert.


How do you mean that? -- Andrei
Apr 30 2015
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mhtggg$26b5$1 digitalmars.com...


 I think we need to stop here. I'll make the PR today for reverting this 
 language change. We can't handle D like a semester science project, 
 because for as long as we do we won't have credibility.



 This trickle of teeny-bit breaking changes for the sake of touted benefits 
 must stop.


This breaking change prevents hard-to-find bugs.  The fact that you needed 
to make trivial changes to 39 places in std.allocator doesn't negate this.
Apr 30 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/15 9:50 AM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mhtggg$26b5$1 digitalmars.com...


 I think we need to stop here. I'll make the PR today for reverting
 this language change. We can't handle D like a semester science
 project, because for as long as we do we won't have credibility.



 This trickle of teeny-bit breaking changes for the sake of touted
 benefits must stop.


 This breaking change prevents hard-to-find bugs.  The fact that you
 needed to make trivial changes to 39 places in std.allocator doesn't
 negate this.


Nothing negates that. It's a judgment call. Please let's stop here. 
Thanks. -- Andrei
Apr 30 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mhto1k$2dk0$1 digitalmars.com...


 Nothing negates that. It's a judgment call. Please let's stop here. 
 Thanks. -- Andrei


Please stop trying to undo this improvement.  Just fix your code and move 
on.
Thanks.
Apr 30 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 1 May 2015 at 01:12:08 UTC, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message 
 news:mhto1k$2dk0$1 digitalmars.com...


 Nothing negates that. It's a judgment call. Please let's stop 
 here. Thanks. -- Andrei


 Please stop trying to undo this improvement.  Just fix your 
 code and move on.
 Thanks.


There is probably a better way to introduce the change, that 
would facilitate the transition but I agree with the feeling. 
std.alocator is probably one of the only piece of code where this 
behavior is justified.
Apr 30 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 1 May 2015 at 02:16:01 UTC, deadalnix wrote:

 On Friday, 1 May 2015 at 01:12:08 UTC, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message 
 news:mhto1k$2dk0$1 digitalmars.com...


 Nothing negates that. It's a judgment call. Please let's stop 
 here. Thanks. -- Andrei


 Please stop trying to undo this improvement.  Just fix your 
 code and move on.
 Thanks.


 There is probably a better way to introduce the change, that 
 would facilitate the transition but I agree with the feeling. 
 std.alocator is probably one of the only piece of code where 
 this behavior is justified.


I guess my earlier post got buried?

http://forum.dlang.org/post/ajrysqkjmlqjlmkipboz forum.dlang.org
Apr 30 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 1 May 2015 at 05:53:36 UTC, Vladimir Panteleev wrote:

 On Friday, 1 May 2015 at 02:16:01 UTC, deadalnix wrote:

 On Friday, 1 May 2015 at 01:12:08 UTC, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message 
 news:mhto1k$2dk0$1 digitalmars.com...


 Nothing negates that. It's a judgment call. Please let's 
 stop here. Thanks. -- Andrei


 Please stop trying to undo this improvement.  Just fix your 
 code and move on.
 Thanks.


 There is probably a better way to introduce the change, that 
 would facilitate the transition but I agree with the feeling. 
 std.alocator is probably one of the only piece of code where 
 this behavior is justified.


 I guess my earlier post got buried?

 http://forum.dlang.org/post/ajrysqkjmlqjlmkipboz forum.dlang.org


Nothing in there tells us how much of these are actually 
justified and how much are bugs.
Apr 30 2015
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 1 May 2015 at 06:02:15 UTC, deadalnix wrote:

 On Friday, 1 May 2015 at 05:53:36 UTC, Vladimir Panteleev wrote:

 I guess my earlier post got buried?

 http://forum.dlang.org/post/ajrysqkjmlqjlmkipboz forum.dlang.org


 Nothing in there tells us how much of these are actually 
 justified and how much are bugs.


And that's your argument?

Consider:

1. I make very heavy use of array-to-bool conversions in my code;
2. To the best of my memory, I've NEVER had a bug due to 
incorrect array-to-bool conversions.

Honestly, pragmatically speaking, I think it would be easier for 
me to start maintaining my forked compiler than to "fix" all 
those warnings, plus the rather long tail of all the other D 
projects I've written over the years that I'm going to have to 
maintain sooner or later.
Apr 30 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 01 May 2015 11:12:12 +1000, Daniel Murphy wrote:


 "Andrei Alexandrescu"  wrote in message
 news:mhto1k$2dk0$1 digitalmars.com...
=20

 Nothing negates that. It's a judgment call. Please let's stop here.
 Thanks. -- Andrei


=20
 Please stop trying to undo this improvement.  Just fix your code and
 move on.
 Thanks.


D is not C++ enough, it needs more legacy warts. after all, the only=20
thing that shows language maturity is how much legacy it accumulated.=
Apr 30 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/15 6:12 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mhto1k$2dk0$1 digitalmars.com...


 Nothing negates that. It's a judgment call. Please let's stop here.
 Thanks. -- Andrei


 Please stop trying to undo this improvement.  Just fix your code and
 move on.
 Thanks.


After we have discussed this matter extensively Walter and I decided to 
move forward and undo this language change.

It's a judgment call. The advantages and disadvantages of this have been 
discussed extensively. We are accountable for decisions like this, and 
we must make the decisions we believe are right. That said, making a 
decision when there are strong feelings and opinions on both sides is 
always difficult.

We would really like to find consensus, but failing that, request your 
indulgence.

Please review: https://github.com/D-Programming-Language/dmd/pull/4623


Thanks,

Andrei
May 01 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 1 May 2015 at 07:06:53 UTC, Andrei Alexandrescu wrote:

 On 4/30/15 6:12 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mhto1k$2dk0$1 digitalmars.com...


 Nothing negates that. It's a judgment call. Please let's stop 
 here.
 Thanks. -- Andrei


 Please stop trying to undo this improvement.  Just fix your 
 code and
 move on.
 Thanks.


 After we have discussed this matter extensively Walter and I 
 decided to move forward and undo this language change.

 It's a judgment call. The advantages and disadvantages of this 
 have been discussed extensively. We are accountable for 
 decisions like this, and we must make the decisions we believe 
 are right. That said, making a decision when there are strong 
 feelings and opinions on both sides is always difficult.

 We would really like to find consensus, but failing that, 
 request your indulgence.

 Please review: 
 https://github.com/D-Programming-Language/dmd/pull/4623


 Thanks,

 Andrei


You say you want to find a consensus, but neither you nor walter 
provide a good sum up of your discussion.

That makes it hard to express any good rebuttal or even be 
understanding of you position.

People here have presented situations where they faced bugs due 
to the current behavior, and even Walter got it wrong in the doc 
in the past (which makes any point saying that the current 
behavior is desirable moot).

Right now, the main reason expressed on your side is the breakage 
in std.allocator, which is known to be fairly different than your 
usual D code. It lets most people here with the feeling that 
breaking our code is no big deal (I have breakage in SDC with 
pretty much every release, usually for the better, sometime 
completely for nothing like when struct construction were not 
lvalues anymore) but breaking yours is.

It has been presented in this thread how the current behavior 
lead to confusion (including, as already mentioned, from Walter 
himself) and how unit tests is likely to NOT catch it, because it 
create this kind of situation where things mostly works, but 
really do not.

The only person here that has presented convincing evidence 
against the change is Vladimir, and that's be really interesting 
to dig into his report to know if all the reported uses are 
correct or if the change discovered some bug in his code.

Possible less painful transition path also have been proposed, 
but none has been discussed.

I sure have made the mistake myself several time and have to make 
people fix their PR because of incorrect use of slice to bool 
conversion on a regular basis, so I'd expect that this damn thing 
to be a positive change. It seems that the majority of people 
agree. Granted, it is not because most people think something 
that it makes it right, but that certainly is a good 
justification to at least provide detailed explanation of why the 
majority is wrong if it is the case.
May 01 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/1/2015 11:09 AM, deadalnix wrote:

 neither you nor walter provide a good sum up of your discussion.


My last post here: https://github.com/D-Programming-Language/dmd/pull/2885
May 01 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 1 May 2015 at 18:45:54 UTC, Walter Bright wrote:

 On 5/1/2015 11:09 AM, deadalnix wrote:

 neither you nor walter provide a good sum up of your 
 discussion.


 My last post here: 
 https://github.com/D-Programming-Language/dmd/pull/2885


So, the plan is to make this a warning ? If so that sound like 
the right way forward.
May 01 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/1/2015 12:06 PM, deadalnix wrote:

 On Friday, 1 May 2015 at 18:45:54 UTC, Walter Bright wrote:

 On 5/1/2015 11:09 AM, deadalnix wrote:

 neither you nor walter provide a good sum up of your discussion.


 My last post here: https://github.com/D-Programming-Language/dmd/pull/2885


 So, the plan is to make this a warning ? If so that sound like the right way
 forward.


You must be looking at something else. What I said, and I quote:
-------------------
I'll try to summarize:
1.this should have been better specified to begin with
2.there are incorrect usages of  if (arr)  in the wild
3.there are correct usages of  if (arr)  in the wild

The case  if (arr) ...arr[0]...  will produce a runtime error, so I am not 
terribly concerned that is a disastrous problem.

What does greatly concern me is this change will break a LOT of long standing, 
correct D code. This is a long standing complaint about D, and has driven away
a 
lot of users. There are also the users driven way because they download
existing 
D code, and that code doesn't compile. They don't really care why it doesn't 
compile, just that it doesn't compile, and they don't look any further.

Is  if(arr)  a problem big enough to merit taking this rather large risk? I'm 
skeptical. I suspect this kind of change and check would be appropriate for a D 
linter, and not be part of the core language.
----------------------
May 01 2015
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 1 May 2015 at 19:45:18 UTC, Walter Bright wrote:

 I suspect this kind of change and check would be appropriate 
 for a D linter, and not be part of the core language.


Yes it would fit nicely into a static analyzer, but DMD is 
currently the only semantic analyzer we have.
May 02 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/2/2015 7:37 AM, Martin Nowak wrote:

 On Friday, 1 May 2015 at 19:45:18 UTC, Walter Bright wrote:

 I suspect this kind of change and check would be appropriate for a D linter,
 and not be part of the core language.


 Yes it would fit nicely into a static analyzer, but DMD is currently the only
 semantic analyzer we have.



I know. The warnings were supposed to be a static analyzer, but quickly turned 
into core language behavior.
May 02 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 2 May 2015 at 14:37:08 UTC, Martin Nowak wrote:

 On Friday, 1 May 2015 at 19:45:18 UTC, Walter Bright wrote:

 I suspect this kind of change and check would be appropriate 
 for a D linter, and not be part of the core language.


 Yes it would fit nicely into a static analyzer, but DMD is 
 currently the only semantic analyzer we have.


dscanner exists
hopefully SDC will improve D tooling.
May 02 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 02 May 2015 19:56:49 +0000, weaselcat wrote:


 On Saturday, 2 May 2015 at 14:37:08 UTC, Martin Nowak wrote:

 On Friday, 1 May 2015 at 19:45:18 UTC, Walter Bright wrote:

 I suspect this kind of change and check would be appropriate for a D
 linter, and not be part of the core language.


 Yes it would fit nicely into a static analyzer, but DMD is currently
 the only semantic analyzer we have.


=20
 dscanner exists


dscanner doesn't do full semantic analysis. and you need that, with full=20
type inference, to catch all cases.=
May 02 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
Back with some data, this change indeed discovered one bug in 
SDC. This was not the first one I'm aware of the confusing 
behavior, and looking for it in PR, still we have at least one 
case left.
May 02 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/2/2015 11:17 AM, deadalnix wrote:

 Back with some data, this change indeed discovered one bug in SDC. This was not
 the first one I'm aware of the confusing behavior, and looking for it in PR,
 still we have at least one case left.


I don't doubt that the change will discover a bug here and there.
May 02 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 April 2015 at 16:49:59 UTC, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message 
 news:mhtggg$26b5$1 digitalmars.com...


 I think we need to stop here. I'll make the PR today for 
 reverting this language change. We can't handle D like a 
 semester science project, because for as long as we do we 
 won't have credibility.



 This trickle of teeny-bit breaking changes for the sake of 
 touted benefits must stop.


 This breaking change prevents hard-to-find bugs.  The fact that 
 you needed to make trivial changes to 39 places in 
 std.allocator doesn't negate this.


I can second this. The code is often not test in an apropriate 
manner.

Let's say you have some code that goes as:

auto foo(T[] ts) {
     if (ts) {
         // ...
     } else {
         // ...
     }
}

Now test :

unitest {
     assert(foo([1, 2, 3]) == ...);
     assert(foo([]) == ...);
}

All tests passes, the code looks correct, but in fact it is going 
to break when foo is called with a drained range, or some slicing 
tat happen to have 0 elements.

That makes for very hard to find bugs.

The current behavior is also inconsistent with general slice 
behavior (which distinguish between identity and value).

People are not making stuff up here. The current behavior is bug 
prone AND inconsistent. And yes, I'm working on SDC's GC, so I'm 
aware that there is code that specifically care about the 
address. This is what the is operator is for.
Apr 30 2015
prev sibling next sibling parent reply Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, Apr 30, 2015 at 8:08 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 This trickle of teeny-bit breaking changes for the sake of touted benefits
 must stop.


This is how you improve the language.  You can disagree with the touted
benefits, but without changes of this sort the language will never get
better.
Apr 30 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/15 10:10 AM, Jeremy Powers via Digitalmars-d wrote:

 On Thu, Apr 30, 2015 at 8:08 AM, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote:


     This trickle of teeny-bit breaking changes for the sake of touted
     benefits must stop.


 This is how you improve the language.


No. -- Andrei
Apr 30 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 30 April 2015 at 17:10:23 UTC, Jeremy Powers wrote:

 On Thu, Apr 30, 2015 at 8:08 AM, Andrei Alexandrescu via 
 Digitalmars-d <
 digitalmars-d puremagic.com> wrote:


 This trickle of teeny-bit breaking changes for the sake of 
 touted benefits
 must stop.


 This is how you improve the language.


Only if you ignore the costs of the change...
Apr 30 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 April 2015 at 18:04:18 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 30 April 2015 at 17:10:23 UTC, Jeremy Powers wrote:

 On Thu, Apr 30, 2015 at 8:08 AM, Andrei Alexandrescu via 
 Digitalmars-d <
 digitalmars-d puremagic.com> wrote:


 This trickle of teeny-bit breaking changes for the sake of 
 touted benefits
 must stop.


 This is how you improve the language.


 Only if you ignore the costs of the change...


This one is quite straightforward. Dfix could probably handle it.
Apr 30 2015
next sibling parent reply "TC" <chalucha gmail.com> writes:
What about less intrusive change as a compromise?


Each warning has some ID and compiler spits it out with the 
description of a problem itself.

Developers than have 4 ways to handle it:
1) ignore it and live with the warning
2) change the code to be correct
3) disable this exact warning type for a whole project
4) disable this exact warning in source file at the place of the 
warning itself

I think that similar approach would be helpful here.
Say we have an Andrei's allocator code which he knows that is 
correct. But spits out a lot of false positive warnings. So at 
the module header he just adds something like:

pragma(disablewarn, 123);

and don't care about it further.

So personally I wouldn't necessarily deprecate current behaviour 
with actual codebreak, but just spit out warning about possible 
error which can be easily taken care of and still can be pretty 
useful to find possible bugs.
Actually that should be major usage for warnings - notify 
developer that something is potentially wrong.


https://msdn.microsoft.com/en-us/library/441722ys.aspx
Apr 30 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 30 Apr 2015 20:27:01 +0000, TC wrote:


 pragma(disablewarn, 123);


please, no! nothing in source code should be able to disable warning --=20
except fixing the code. and such pragma simply ugly.=
Apr 30 2015
prev sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote:

 This one is quite straightforward. Dfix could probably handle 
 it.


I'd have to rewrite dfix on top of SDC to get this working. dfix 
can only work at the lexical and AST level at the moment. As soon 
as you need information like "Is this a dynamic array?" you need 
a compiler.

I could try using DCD's "suhmantick analisyss"[1] code to try to 
get this to work, but it wouldn't work correctly in a lot of 
cases.

[1] it's really dumb, but works well enough for an auto-complete 
engine
Apr 30 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 April 2015 at 21:58:17 UTC, Brian Schott wrote:

 On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote:

 This one is quite straightforward. Dfix could probably handle 
 it.


 I'd have to rewrite dfix on top of SDC to get this working. 
 dfix can only work at the lexical and AST level at the moment. 
 As soon as you need information like "Is this a dynamic array?" 
 you need a compiler.

 I could try using DCD's "suhmantick analisyss"[1] code to try 
 to get this to work, but it wouldn't work correctly in a lot of 
 cases.

 [1] it's really dumb, but works well enough for an 
 auto-complete engine


I'm sure that with "suhmantick analisyss" one can get a good cunk 
of the tests (not all, but something large enough). This paired 
with making the thing a warning rather than an error, should 
provide an easy transition path.
Apr 30 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 30 April 2015 at 21:58:17 UTC, Brian Schott wrote:

 On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote:

 This one is quite straightforward. Dfix could probably handle 
 it.


 I'd have to rewrite dfix on top of SDC to get this working. 
 dfix can only work at the lexical and AST level at the moment. 
 As soon as you need information like "Is this a dynamic array?" 
 you need a compiler.

 I could try using DCD's "suhmantick analisyss"[1] code to try 
 to get this to work, but it wouldn't work correctly in a lot of 
 cases.

 [1] it's really dumb, but works well enough for an 
 auto-complete engine


How about parsing DMD's output (with -vcolumns)?
May 01 2015
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 1 May 2015 at 07:15:07 UTC, Vladimir Panteleev wrote:

 On Thursday, 30 April 2015 at 21:58:17 UTC, Brian Schott wrote:

 On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote:

 This one is quite straightforward. Dfix could probably handle 
 it.


 I'd have to rewrite dfix on top of SDC to get this working. 
 dfix can only work at the lexical and AST level at the moment. 
 As soon as you need information like "Is this a dynamic 
 array?" you need a compiler.

 I could try using DCD's "suhmantick analisyss"[1] code to try 
 to get this to work, but it wouldn't work correctly in a lot 
 of cases.

 [1] it's really dumb, but works well enough for an 
 auto-complete engine


 How about parsing DMD's output (with -vcolumns)?


Erm, never mind. I forgot this is all assuming the compiler
change is going away.
May 01 2015
prev sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Thursday, 30 April 2015 at 15:08:00 UTC, Andrei Alexandrescu 
wrote:

 On 4/30/15 4:46 AM, Daniel Murphy wrote:

 "Vladimir Panteleev"  wrote in message
 news:ajrysqkjmlqjlmkipboz forum.dlang.org...


 On Wednesday, 29 April 2015 at 19:15:46 UTC, Jonathan M Davis
 wrote:

 but std.allocator is definitely not your average code


 OK, I'm tired of hearing this argument.


 It's valid though.


 I think we need to stop here. I'll make the PR today for 
 reverting this language change. We can't handle D like a 
 semester science project, because for as long as we do we won't 
 have credibility.

 This trickle of teeny-bit breaking changes for the sake of 
 touted benefits must stop.

 In the future please do not make breaking changes without my 
 and Walter's approval.


 Thanks,

 Andrei


OK so, please revert this one:
https://github.com/D-Programming-Language/dmd/commit/2869ee9c1fb64f08b51d8d07ce72701dda4a6fae

and this one:
http://forum.dlang.org/thread/ibupwrwsgjvrjwabhmjd forum.dlang.org
Apr 30 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 April 2015 at 23:12:18 UTC, Daniel Kozak wrote:

 OK so, please revert this one:
 https://github.com/D-Programming-Language/dmd/commit/2869ee9c1fb64f08b51d8d07ce72701dda4a6fae



WAT ?


 and this one:
 http://forum.dlang.org/thread/ibupwrwsgjvrjwabhmjd forum.dlang.org


I'm not sure I get the details of that one, would you mind to sum 
up the crux of the issue ?
Apr 30 2015
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 01 May 2015 00:12:53 +0000
deadalnix via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Thursday, 30 April 2015 at 23:12:18 UTC, Daniel Kozak wrote:

 OK so, please revert this one:
 https://github.com/D-Programming-Language/dmd/commit/2869ee9c1fb64f08b51d8d07ce72701dda4a6fae


 
 
 WAT ?
 

 and this one:
 http://forum.dlang.org/thread/ibupwrwsgjvrjwabhmjd forum.dlang.org


 
 I'm not sure I get the details of that one, would you mind to sum 
 up the crux of the issue ?


struct S {
    immutable A = 5;
    int x;
}

int main() {

    S s;
    assert(s.sizeof == s.x.sizeof);
    assert(s.sizeof == s.x.sizeof + s.A.sizeof);
    return 0;
}

before 2.067:
core.exception.AssertError test.d(12): Assertion failure

after 2.067:
core.exception.AssertError test.d(11): Assertion failure



I do not want to change any of the issue above, I just do not understand why
some breaking changes are OK, and some other are not so ok.
May 01 2015
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 1 May 2015 at 08:40:25 UTC, Daniel Kozak wrote:

 <snip>

 I just do not understand why
 some breaking changes are OK, and some other are not so ok.


+1.... but, again, I'm hopeless that W+A will understand the 
break-my-code spirit...

/P
May 01 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, May 01, 2015 08:51:10 Paolo Invernizzi via Digitalmars-d wrote:

 On Friday, 1 May 2015 at 08:40:25 UTC, Daniel Kozak wrote:

 <snip>

 I just do not understand why
 some breaking changes are OK, and some other are not so ok.


 +1.... but, again, I'm hopeless that W+A will understand the
 break-my-code spirit...


Walter tends to err on the side of wanting to break no code whatsoever, and
he almost never seems to understand when folks actually _want_ their code
broken, because they consider the current situation to be worse than having
their code temporarily broken (e.g. because leaving the current state of
things in place would result in far more bugs in the future). In light of
that, I'm actually kind of surprised that he's agreed to some of the code
breakage that we've done (e.g. making implicit falthrough in switch
statements illegal).

But to be fair, it's often hard to know when it's worth making a breaking
change even if you're willing to make them in order to catch and prevent
bugs or to clean-up a language featuer or whatever. And pretty much every
time you make such a change, some folks will be very happy about, whereas
others will be very _un_happy about it. So, to some extent, you just can't
win. And when that's the case, it's frequently easier to just leave things
as they are and avoid making breaking changes even if it might be better if
they were made.

- Jonathan M Davis
May 01 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:

 Walter tends to err on the side of wanting to break no code 
 whatsoever, and
 he almost never seems to understand when folks actually _want_ 
 their code
 broken, because they consider the current situation to be worse 
 than having
 their code temporarily broken (e.g. because leaving the current 
 state of
 things in place would result in far more bugs in the future).


It's not really as simple as that, and I think I understand W & 
A's position here.

It seems that every once in a while, someone on Reddit etc. is 
going to say something along the lines of "I once tried to 
compile some code written in D, and it didn't compile with none 
of the three compilers. I'm not familiar with the language or 
code, so fixing it was out of the question, and so was randomly 
trying old compiler versions. If other people are going to have 
the same experience using MY code, then I don't see the point in 
investing time in D."

I was in the "break my code" camp for a long time, but this has 
gradually changed as the amount of D code I've written grew. Let 
me tell you, it's totally not fun when you need to quickly fix a 
D program you wrote 3 years ago because something is on fire and 
it needs fixing now, and discover you have to make a bunch of 
changes just to get it to compile again. The alternative is using 
an older compiler, and DVM helps with that - but this doesn't 
work if the fix is in a library which is not compatible with 
older compiler versions.

I would love a cleaner D language, if only it could be enforced 
just onto NEW code.
May 01 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/1/2015 2:28 AM, Vladimir Panteleev wrote:

 I was in the "break my code" camp for a long time, but this has gradually
 changed as the amount of D code I've written grew. Let me tell you, it's
totally
 not fun when you need to quickly fix a D program you wrote 3 years ago because
 something is on fire and it needs fixing now, and discover you have to make a
 bunch of changes just to get it to compile again. The alternative is using an
 older compiler, and DVM helps with that - but this doesn't work if the fix is
in
 a library which is not compatible with older compiler versions.


I've had the mispleasure several times of reaching back to update some older D 
code of mine, that works fine, and finding not only will it not compile, I have 
to re-architect parts of it.

The situation was so bad I wound up creating:

     https://github.com/DigitalMars/undeaD

and if *I* find this annoying, irritating, disheartening, etc., I can only 
imagine how others feel about it.

Sometimes the older code is complex, underdocumented, and I don't remember how 
it worked or how it needs to be re-architected. But it does work, it just 
doesn't compile anymore.

Imagine you find some cool D library, download it, and find it doesn't compile. 
How many of you are going to fix it? Or are you just going to chuck it to
/dev/null?

How many users have we lost because of this?

This really blows. And things like that isnan => isNaN really has GOT TO STOP. 
Just today I found it broke some older piece of code I had that's perfectly
correct.

We need to be working on things that MATTER. What happens with every Reddit
post 
about D? No matter the topic, it always becomes about D not being usable
without 
the GC.

A big piece of the fix for that is going through Phobos and fixing code that 
returns gc allocated arrays with algorithms that return ranges.

Why am I the only one working on that? I don't remember anyone having a problem 
with isnan.

I'm willing to break existing code for a large benefit. Not a small one. And 
certainly not when the benefit is zero, like the isnan renaming. And I'm
willing 
to break code that relied on bugs in the compiler.
May 01 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 01 May 2015 02:55:00 -0700, Walter Bright wrote:


 Imagine you find some cool D library, download it, and find it doesn't
 compile.
 How many of you are going to fix it? Or are you just going to chuck it
 to /dev/null?
=20
 How many users have we lost because of this?


zero. if that library is SO old, it is unmaintained anyway, so there will=20
be no not only new features, but no bugfixes too. anyone wanting to use=20
such library in new code is insane.


 This really blows. And things like that isnan =3D> isNaN really has GOT T=


O

 STOP.


sed -r 's/\bisnan\b/isNaN/'


 We need to be working on things that MATTER.


language consistency IS matter. i wouldn't even try to explain newcomer=20
what `if (arr)` really means, why it means that, and why in the name of=20
hell he should care about `arr.ptr`, while in all other places it doesn't=20
matter. and i can tell you how many users you lost due to THIS: at least=20
ten. ten real users vs ??? imaginary users.


 What happens with every
 Reddit post about D? No matter the topic, it always becomes about D not
 being usable without the GC.


why should anyone care about what is going on on reddit? ah, i know. it's=20
'cause Random Reddit Poster, who never wrote something bigger than=20
"hello, world" in D is first-class citizen, and people who using D every=20
day to write all kind of programs are second-class citizens.


 Why am I the only one working on that?


maybe 'cause other people who can devote their time to this doesn't see=20
random reddit mumbling as a serious motivation?


 I'm willing to break existing code for a large benefit. Not a small one.


having consistent language is a large benefit. but it's not immediate one.


=
May 01 2015
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 1 May 2015 at 09:54:43 UTC, Walter Bright wrote:

 I've had the mispleasure several times of reaching back to 
 update some older D code of mine, that works fine, and finding 
 not only will it not compile, I have to re-architect parts of 
 it.

 The situation was so bad I wound up creating:

     https://github.com/DigitalMars/undeaD

 and if *I* find this annoying, irritating, disheartening, etc., 
 I can only imagine how others feel about it.


Why is that a valid argument AGAINST the change, while the exact 
same argument was not valid the other way around. You were 
confused writing the doc in the first place, and if *You* find it 
confusing, you should be able to imagine how others feel about it.

I'm sorry, but it is just backward rationalization.


 Imagine you find some cool D library, download it, and find it 
 doesn't compile. How many of you are going to fix it? Or are 
 you just going to chuck it to /dev/null?

 How many users have we lost because of this?

 This really blows. And things like that isnan => isNaN really 
 has GOT TO STOP. Just today I found it broke some older piece 
 of code I had that's perfectly correct.


This breaks code without fixing anything. So, because of some 
stupid change have been made in the past, that mean that all 
change should be avoided ? That is once again bogus logic.


 We need to be working on things that MATTER. What happens with 
 every Reddit post about D? No matter the topic, it always 
 becomes about D not being usable without the GC.


This change expose bugs. It does matter. isnan vs isNaN does not. 
It does not matter. This is not about isNan or about the GC, so 
there is no point in bringing these subjects into the 
conversation unless the goal is to make everything confusing and 
OT.


 A big piece of the fix for that is going through Phobos and 
 fixing code that returns gc allocated arrays with algorithms 
 that return ranges.


True, but OT.


 Why am I the only one working on that? I don't remember anyone 
 having a problem with isnan.


Red herring. This is not about isnan, never was, never will be. 
You are the one trying to bring that up.
May 01 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 1 May 2015 at 09:54:43 UTC, Walter Bright wrote:

 This really blows. And things like that isnan => isNaN really 
 has GOT TO STOP. Just today I found it broke some older piece 
 of code I had that's perfectly correct.


I don't know anything about that one, so if that's a recent one,
I missed it, but we've been rejecting name changes like that for
a while now. I think that it's been a couple of years since the
last time I saw one merged in. There might be an exception or two
that I don't know about, but we've pretty much stopped doing
precisely because it's an aesthetic thing but does not actually
catch bugs or anything like that.

That being said, something like disallowing if(arr) is completely
different. It's like disallowing implicit fallthrough in switch
statements. The change may or may not be worth making, but it's
_not_ for aesthetics. It's in order to catch and prevent bugs.
And for whatever reason, you never seem to understand that not
all breaking changes are equal. Some - particularly those that
catch or prevent bugs - are frequently welcomed, and it annoys
people quite a bit when such changes are refused. I know that Don
loves to complain about that. Changes like getting rid of
implicit fallthrough in switch statements are desirable, because
it catches and prevents bugs. And disallowing if(arr) is in the
same boat. Maybe it's not used incorrectly on a frequent enough
basis to be worth the code breakage. That's an open question. But
the change is targeted at bugs, not aesthetics, like isnan =>
isNAN is. So, the two cases are completely different.

Personally, I'd advise that no one ever use if(arr) and that they
should always do if(arr !is null) or if(!arr.empty) so that it's
clear what they intended and so that they don't accidentally
check for null when they intended to check for empty. So, I think
that we would very much be better off with if(arr) being illegal.
I don't think that it's the end of the world if we keep it, just
like it wouldn't have been the end of the world if we'd keep
implicit fallthrough for switch statements, but I do think that
it's worth making the change, because it catches and prevents
bugs.

The only problem I see with making the change has been a couple
of very vocal folks who have some code where they used if(arr)
correctly, and they don't want to change their code, which I
understand, and maybe that's enough that we won't make the change
(since it's Andrei and Cybershadow who are complaining), but most
of us consider if(arr) (or any case where an array is implicitly
converted to bool) too error-prone to use and would _want_ it
found and removed from our code bases. And it _is_ the sort of
thing that many newbies will screw up.

Regardless, whether we make the change with if(arr) or not, I
think that main point here is that not all breaking changes are
equal. Some are for aesthetic purposes (e.g. isnan => isNaN) and
don't really help much beyond having the library be more
consistent and easier to learn, whereas others actually find and
prevent bugs or allow us to implement some new idiom that we
think is important. I really don't think that the simple fact
that a change will break existing code in and of itself says
whether we should make the change. It makes it so that the change
has to provide _much_ greater value than would be the case for a
non-breaking change - the bar on such changes needs to be higher
- but sometimes, they're worth it, and it seems like you tend to
reject any breaking change even if everyone else involved thinks
that it's worth it.

We _should_ be rejecting aesthetic changes at this point, but
that doesn't mean that we should reject _all_ breaking changes.
Given your attitude on stuff like this, I'm honestly very
surprised that you ever let implicit fallthrough on switch
statements be made illegal.

- Jonathan M Davis
May 02 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 2 May 2015 at 09:20:50 UTC, Jonathan M Davis wrote:

 The only problem I see with making the change has been a couple
 of very vocal folks
 [...]
 (since it's Andrei and Cybershadow who are complaining)


"You either die a hero, or live long enough to see yourself 
become the villain."


 Given your attitude on stuff like this, I'm honestly very
 surprised that you ever let implicit fallthrough on switch
 statements be made illegal.


That was 4 years ago (v2.054). For some perspective, that was the 
same version when  safe and  property were introduced.
May 02 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/15 4:06 AM, Vladimir Panteleev wrote:

 On Saturday, 2 May 2015 at 09:20:50 UTC, Jonathan M Davis wrote:

 The only problem I see with making the change has been a couple
 of very vocal folks
 [...]
 (since it's Andrei and Cybershadow who are complaining)


 "You either die a hero, or live long enough to see yourself become the
 villain."


 Given your attitude on stuff like this, I'm honestly very
 surprised that you ever let implicit fallthrough on switch
 statements be made illegal.


 That was 4 years ago (v2.054). For some perspective, that was the same
 version when  safe and  property were introduced.


One data point: dlang.org visits in March have increased 50 times 
between 2011 and 2015. (Visits are defined per 
http://www.webalizer.org/webalizer_help.html.) I'll have more data at my 
DConf talk. -- Andrei
May 02 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/2/2015 4:06 AM, Vladimir Panteleev wrote:

 On Saturday, 2 May 2015 at 09:20:50 UTC, Jonathan M Davis wrote:

 The only problem I see with making the change has been a couple
 of very vocal folks
 [...]
 (since it's Andrei and Cybershadow who are complaining)


 "You either die a hero, or live long enough to see yourself become the
villain."


Ironic, as I recently watched the series "Oppenheimer".
May 02 2015
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 May 2015 at 11:28, Vladimir Panteleev via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:

 Walter tends to err on the side of wanting to break no code whatsoever,
 and
 he almost never seems to understand when folks actually _want_ their code
 broken, because they consider the current situation to be worse than
 having
 their code temporarily broken (e.g. because leaving the current state of
 things in place would result in far more bugs in the future).



 It's not really as simple as that, and I think I understand W & A's position
 here.

 It seems that every once in a while, someone on Reddit etc. is going to say
 something along the lines of "I once tried to compile some code written in
 D, and it didn't compile with none of the three compilers. I'm not familiar
 with the language or code, so fixing it was out of the question, and so was
 randomly trying old compiler versions. If other people are going to have the
 same experience using MY code, then I don't see the point in investing time
 in D."

 I was in the "break my code" camp for a long time, but this has gradually
 changed as the amount of D code I've written grew. Let me tell you, it's
 totally not fun when you need to quickly fix a D program you wrote 3 years
 ago because something is on fire and it needs fixing now, and discover you
 have to make a bunch of changes just to get it to compile again. The
 alternative is using an older compiler, and DVM helps with that - but this
 doesn't work if the fix is in a library which is not compatible with older
 compiler versions.

 I would love a cleaner D language, if only it could be enforced just onto
 NEW code.


pragma(old_code);
May 01 2015
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 1 May 2015 at 09:28:58 UTC, Vladimir Panteleev wrote:

 On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:

 Walter tends to err on the side of wanting to break no code 
 whatsoever, and
 he almost never seems to understand when folks actually _want_ 
 their code
 broken, because they consider the current situation to be 
 worse than having
 their code temporarily broken (e.g. because leaving the 
 current state of
 things in place would result in far more bugs in the future).


 It's not really as simple as that, and I think I understand W & 
 A's position here.

 It seems that every once in a while, someone on Reddit etc. is 
 going to say something along the lines of "I once tried to 
 compile some code written in D, and it didn't compile with none 
 of the three compilers. I'm not familiar with the language or 
 code, so fixing it was out of the question, and so was randomly 
 trying old compiler versions. If other people are going to have 
 the same experience using MY code, then I don't see the point 
 in investing time in D."

 I was in the "break my code" camp for a long time, but this has 
 gradually changed as the amount of D code I've written grew. 
 Let me tell you, it's totally not fun when you need to quickly 
 fix a D program you wrote 3 years ago because something is on 
 fire and it needs fixing now, and discover you have to make a 
 bunch of changes just to get it to compile again. The 
 alternative is using an older compiler, and DVM helps with that 
 - but this doesn't work if the fix is in a library which is not 
 compatible with older compiler versions.

 I would love a cleaner D language, if only it could be enforced 
 just onto NEW code.


Most of commercial code _is_ maintained, fix it for a change like 
this one is _trivial_.

This apply to _every programming language_ : we are doing it 
right now, today, to upgrade a commercial library that we sell to 
a different visual studio edition.

Hunting for bugs is wasted time.
Explaining the pitfalls of the language is wasted time.
Explaining the inconsistency of the language is wasted time.
Reling on convenctions instead of being forced by a tool is 
wasted time.

This comes from my experience, as the CTO of a company with a big 
D codebase: reddit turned out to be some sort of pestilence for 
D, IMHO...

/P
May 01 2015
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 May 2015 at 12:03, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 1 May 2015 at 11:28, Vladimir Panteleev via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:

 Walter tends to err on the side of wanting to break no code whatsoever,
 and
 he almost never seems to understand when folks actually _want_ their code
 broken, because they consider the current situation to be worse than
 having
 their code temporarily broken (e.g. because leaving the current state of
 things in place would result in far more bugs in the future).



 It's not really as simple as that, and I think I understand W & A's position
 here.

 It seems that every once in a while, someone on Reddit etc. is going to say
 something along the lines of "I once tried to compile some code written in
 D, and it didn't compile with none of the three compilers. I'm not familiar
 with the language or code, so fixing it was out of the question, and so was
 randomly trying old compiler versions. If other people are going to have the
 same experience using MY code, then I don't see the point in investing time
 in D."

 I was in the "break my code" camp for a long time, but this has gradually
 changed as the amount of D code I've written grew. Let me tell you, it's
 totally not fun when you need to quickly fix a D program you wrote 3 years
 ago because something is on fire and it needs fixing now, and discover you
 have to make a bunch of changes just to get it to compile again. The
 alternative is using an older compiler, and DVM helps with that - but this
 doesn't work if the fix is in a library which is not compatible with older
 compiler versions.

 I would love a cleaner D language, if only it could be enforced just onto
 NEW code.


 pragma(old_code);



Actually, one could even take inspiration from Perl's 'use VERSION' as
a way tell the compiler to use the semantics/warnings of a previous
release.  But then it comes down to a feeling of some competing
element between cleaner D language vs. cleaner D implementation.

Iain.
May 01 2015
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, May 01, 2015 10:40:46 Daniel Kozak via Digitalmars-d wrote:

 I do not want to change any of the issue above, I just do not understand why
 some breaking changes are OK, and some other are not so ok.


Well, fixing bugs often results in breaking changes. Sometimes, it's
determined that something causes enough bugs that we make it illegal (e.g.
implicit fallthrough in switch statements), and that would be a breaking
change (though in principle, it finds and prevents enough bugs to be worth
it). Sometimes, we're forced to make changes in the language to enable
something we want or need to do or to make an existing feature work
correctly, and that can result in breaking changes. Sometimes, we decide
that a previous design decision was enough of a mistake to be worth changing
even though it breaks code. There are a number of reasons for it.

Ultimately, the question is whether the changes are worth the problems that
the breakage causes (which often depends on how much code is likely to break
and how critical it is that the change be made; e.g. fixing a bug is pretty
much always going to be worth the breakage, whereas making a design change
often wouldn't be). And whether the change is made tends to depend on who's
involved in the decision. Some devs are more willing to make breaking
changes than others, and it's not always clear whether something is really a
bug or just an unfortunate result of other design decisions. Walter tends to
reject most breaking changes, but he might consider something to be a bug
that needs to be fixed whereas someone else thinks that it's legitimate
behavior. And Walter doesn't review every pull request, so sometimes,
breaking changes are made without his knowledge or consent.

We make _far_ fewer breaking changes than we used to, and the bar has been
raised considerably, but we do upon occasion make breaking changes when we
think that it's worth it, and that's always going to be on a case-by-case
basis. So, it's very hard to give a definitive answer as to what is and
isn't an acceptable breaking change. It really depends on the change in
question.

In general, I think that most breaking changes occur due to regressions that
aren't caught, in which case, they're bugs, not purposeful changes. And
while we're doing better at catching and preventing regressions, we
definitely don't get them all. We really need more folks trying out the
betas with their projects and reporting any issues that they find in order
to get anywhere near catching them all (and we'll probably never catch 100%
of them, particularly if a regression affects only rare cases). So,
frequently, code breakage is completely accidental.

- Jonathan M Davis
May 01 2015
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 29 April 2015 at 17:35:58 UTC, Andrei Alexandrescu 
wrote:

 I have no doubt the change can find certain errors. Problem is 
 false positives. FWIW these are the changes I had to operate on 
 std.allocator to make it work with the new compiler.


That code is contrived, confusing and consequently bug-prone, I'd 
say compiler complaints are legit in those cases, they are not as 
false positive as you want to make it look like. All in all your 
argument is quite biased and impractical.
Apr 30 2015
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I have no doubt the change can find certain errors. Problem is 
 false positives. FWIW these are the changes I had to operate on 
 std.allocator to make it work with the new compiler. One per 
 194 lines on average, all false positives:


Just fix your code Andrei Alexandrescu :-)

Bye,
bearophile
Apr 30 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 29 April 2015 at 04:38:12 UTC, Steven Schveighoffer 
wrote:

 FYI, Andrei and Walter are reversing this change barring any 
 new evidence it's helpful to people. Please speak up if you 
 disagree.

 https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912

 -Steve


I don't have precise number to show, but I've been bitten by if 
(arr) doing null check rather than length check more than once.

The most problematic part of it is that it is frequent to have 
empty slice having a null pointer, so the code is likely to pass 
testing, while not doing what you expect it to do, and will break 
later in some bizarre way.

More generally, it is a identity vs equality problem. Slices have 
a semantic where equality is not identity ( == is different than 
is ) so the current behavior is inconsistent.
Apr 29 2015