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. Python got it right, in C# difference between null and empty 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.
$#^% $. i should really read the whole topic before writing answers.=
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?

I'm the C# guy and they solve these problems just with warnings. 
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.

More about C# pragmas for warning handling: 
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