Re: Thoughts on some code breakage with 2.074
On 5/11/17 7:52 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 11, 2017 at 07:46:24PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
But this still doesn't mean that *all* bool conversions are value
based. In at least the struct and class cases, more than just the bits
are checked.
[...]
Wait, what? You can use a *struct* as a bool condition?!
I tried this:
import std.stdio;
struct S {}
void main() {
S s;
if (s) { writeln("WAT"); }
}
But the compiler (rightly) said:
test.d(5): Error: expression s of type S does not have a boolean value
Or were you talking about structs that define opCast!bool? (In which
case it's certainly intentional and doesn't pose a problem.)
Yes, I was talking about that.
I can see classes being usable in conditions, though, since they're
essentially pointers hiding behind an abstraction. Still, it doesn't
quite sit right with me. For example:
class C { }
class D { bool opCast(T : bool)() { return false; } }
void main() {
C c;
D d = new D;
if (!c) { ... } // OK, expected semantics
if (!d) { ... } // *** What happens here?
}
I have totally misremembered the thing of classes and invariants. So my
statement on that is wrong.
It's when you *assert* a class instance that the invariant is checked,
not when used in an if condition.
Testing out your question, the opCast to bool doesn't apply for classes.
Just the reference is checked against null. You have to write
cast(bool)d to trigger the opCast.
So classes are just like pointers. Really only structs offer some
semblance of control for use in if statements.
-Steve
Re: Thoughts on some code breakage with 2.074
On Thu, May 11, 2017 at 07:46:24PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> But this still doesn't mean that *all* bool conversions are value
> based. In at least the struct and class cases, more than just the bits
> are checked.
[...]
Wait, what? You can use a *struct* as a bool condition?!
I tried this:
import std.stdio;
struct S {}
void main() {
S s;
if (s) { writeln("WAT"); }
}
But the compiler (rightly) said:
test.d(5): Error: expression s of type S does not have a boolean value
Or were you talking about structs that define opCast!bool? (In which
case it's certainly intentional and doesn't pose a problem.)
I can see classes being usable in conditions, though, since they're
essentially pointers hiding behind an abstraction. Still, it doesn't
quite sit right with me. For example:
class C { }
class D { bool opCast(T : bool)() { return false; } }
void main() {
C c;
D d = new D;
if (!c) { ... } // OK, expected semantics
if (!d) { ... } // *** What happens here?
}
Whereas had the last two lines been written:
if (c is null) { ... }
if (d is null) { ... }
the intent would be much clearer. (And of course, d would be usable
without "is null" if you actually intended to invoke opCast!bool.)
T
--
In a world without fences, who needs Windows and Gates? -- Christian Surchi
Re: Thoughts on some code breakage with 2.074
On Thu, May 11, 2017 at 08:21:46AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> I don't ever remember if(ptr) being deprecated. In fact, I'd go as far
> as saying that maybe H.S. Teoh misremembers the array thing as
> pointers.
>
> The biggest reason is that a huge useful pattern with this is:
>
> if(auto x = key in someAA)
> {
>// use *x without more hash lookup costs.
> }
>
> I can't imagine anyone attempted to force this to break without a loud
> backlash. I think if(ptr) is mostly universally understood to mean the
> pointer is not null.
[...]
Since the accuracy of my memory was questioned, I went back to look at
the code in question, and indeed I did misremember it, but it was not
with arrays, it was with casting pointers to bool. And it was in a
while-condition, not an if-condition. Here's a simplified version of
the original code:
struct Op {...}
Op* getOp(...) { ... }
...
Op* op;
while (!input.empty && cast(bool)(op = getOp(...))) { ... }
The cast(bool) used to be accepted up to a certain version (it was in
the code from when I first wrote it around 2012), then around 2013 it
became a compile error, which forced me to rewrite it as:
struct Op {...}
Op* getOp(...) { ... }
...
Op* op;
while (!input.empty && (op = getOp(...)) !is null) { ... }
which is much more readable and documents intent more clearly.
I originally wrote the cast(bool) because without it the compiler
rejects using assignment in an while-condition. I suppose the reasoning
is that it's too easy to mistakenly write `while (a=b)` instead of
`while (a==b)`. In modern C compilers, an extra set of parentheses
usually silenced the compiler warning about a possible typo of ==, but
in D even with parentheses the compiler would reject it.
So all things considering, this little anecdote represents the following
progression in readability (the first 2 steps are hypothetical, since
they're only permitted in C):
while (a = b) ... // in C, error-prone, could be typo
while ((a = b)) ... // still in C, marginally better
while (cast(bool)(a = b)) // early D, the conversion is now
explicit
while ((a = b) !is null)// present-day D, finally intent is
clear
T
--
By understanding a machine-oriented language, the programmer will tend to use a
much more efficient method; it is much closer to reality. -- D. Knuth
Re: Thoughts on some code breakage with 2.074
On 5/11/17 7:12 PM, deadalnix wrote: On Thursday, 11 May 2017 at 12:26:11 UTC, Steven Schveighoffer wrote: if(arr) -> same as if(arr.ptr) Nope. It is: if(arr) -> same as if(((cast(size_t) arr.ptr) | arr.length) != 0) Should we conclude from the fact that absolutely nobody gets it right in this very forum that nobody will get it right outside ? I'll let you judge. But this still doesn't mean that *all* bool conversions are value based. In at least the struct and class cases, more than just the bits are checked. -Steve
Re: Thoughts on some code breakage with 2.074
On 5/11/17 7:12 PM, deadalnix wrote:
On Thursday, 11 May 2017 at 12:26:11 UTC, Steven Schveighoffer wrote:
if(arr) -> same as if(arr.ptr)
Nope. It is:
if(arr) -> same as if(((cast(size_t) arr.ptr) | arr.length) != 0)
Should we conclude from the fact that absolutely nobody gets it right in
this very forum that nobody will get it right outside ? I'll let you judge.
Yep, you are right. It's checking the length too. Although in practice,
almost never do you have a null pointer array with non-zero length.
Just for your amusement, I wrote the test this way :)
Stevens-MacBook-Pro:testd steves$ cat testifarrptr.d
void main()
{
char[] x = null;
x = x.ptr[0 .. 1];
if(x)
{
import std.stdio;
writeln("ok, deadalnix was right");
}
}
Stevens-MacBook-Pro:testd steves$ dmd -run testifarrptr.d
ok, deadalnix was right
-Steve
Re: Thoughts on some code breakage with 2.074
On Thursday, 11 May 2017 at 12:26:11 UTC, Steven Schveighoffer wrote: if(arr) -> same as if(arr.ptr) Nope. It is: if(arr) -> same as if(((cast(size_t) arr.ptr) | arr.length) != 0) Should we conclude from the fact that absolutely nobody gets it right in this very forum that nobody will get it right outside ? I'll let you judge.
Re: Thoughts on some code breakage with 2.074
On Thursday, 11 May 2017 at 12:21:46 UTC, Steven Schveighoffer wrote: I can't imagine anyone attempted to force this to break without a loud backlash. I think if(ptr) is mostly universally understood to mean the pointer is not null. -Steve It is not a problem for pointer because for pointer identity and equality are the same thing. It isn't for slices.
Re: Thoughts on some code breakage with 2.074
On 5/11/17 5:37 AM, deadalnix wrote: On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote: Bummer for H. S. Teoh I guess... :/ Although I prefer explicit over implicit in most cases, I've never graduated from if(p) and still using it happily. :) Ali All bool conversions in D are value based, not identity based. Not only this is error prone, this is inconsistent. What does "value based" and "identity based" mean? bool conversions vary widely and allow a lot of flexibility (at least for structs): if(arr) -> same as if(arr.ptr) if(someInt) -> same as if(someInt != 0) if(someObject) -> if(someObject !is null && someObject.invariant) if(someStruct) -> if(someStruct.opCast!(bool)) -Steve
Re: Thoughts on some code breakage with 2.074
On 5/10/17 2:49 PM, Jonathan M Davis via Digitalmars-d wrote:
On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote:
On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
> I even appreciate breakages that eventually force me to write more
>
> readable code! A not-so-recent example:
>/* Used to work, oh, I forget which version now, but it used to
>
> * work: */
>
>MyType* ptr = ...;
>if (someCondition && ptr) { ... }
>
> After upgrading the compiler, I get a warning that using a pointer as a
> condition is deprecated. At first I was mildly annoyed... but then to
>
> make the warning go away, I wrote this instead:
>/* Look, ma! Self-documenting, readable code! */
>MyType* ptr = ...;
>if (someCondition && ptr !is null) { ... }
Can you show an example please. I don't see this being required by
2.074.0 (compiled with -w -de).
I think that that's the one that Andrei and Vladimir didn't like, because
they actually used the conversion to bool correctly in their code a bunch
(whereas most everyone else thought that it was too error prone), and the
deprecation ended up being removed.
I think that was the if(array) fiasco.
I don't ever remember if(ptr) being deprecated. In fact, I'd go as far
as saying that maybe H.S. Teoh misremembers the array thing as pointers.
The biggest reason is that a huge useful pattern with this is:
if(auto x = key in someAA)
{
// use *x without more hash lookup costs.
}
I can't imagine anyone attempted to force this to break without a loud
backlash. I think if(ptr) is mostly universally understood to mean the
pointer is not null.
-Steve
Re: Thoughts on some code breakage with 2.074
On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote: On 05/10/2017 11:49 AM, Jonathan M Davis via Digitalmars-d wrote: > On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote: >> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote: >> > After upgrading the compiler, I get a warning that using a pointer as a >> > condition is deprecated. > I think that that's the one that Andrei and Vladimir didn't like, because > they actually used the conversion to bool correctly in their code a bunch > (whereas most everyone else thought that it was too error prone), and the > deprecation ended up being removed. > > - Jonathan M Davis Bummer for H. S. Teoh I guess... :/ Although I prefer explicit over implicit in most cases, I've never graduated from if(p) and still using it happily. :) Yes, me too (in C). It is conceptually imho ok to use it that way as a pointer does have a boolean semantic, either it is a valid pointer or it is not. The value of the pointer itself is only in special cases relevant (cases in which they have to be converted to an integral type anyway) and is in any case extremely machine dependent. One can even make the case that checking "ptr !is null" or in C "ptr != 0" is inconsistent as it is the only operation where the value of a pointer is used, which is, at least for C a source of confusion. The 0 value in a pointer context will not necessarily compile to a 0 value in the generated assembly. Some machines have null ptrs that are not represented by 0 bits integral values and the C standard has to take these (granted obsolete) into account.
Re: Thoughts on some code breakage with 2.074
On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote: Bummer for H. S. Teoh I guess... :/ Although I prefer explicit over implicit in most cases, I've never graduated from if(p) and still using it happily. :) Ali All bool conversions in D are value based, not identity based. Not only this is error prone, this is inconsistent.
Re: Thoughts on some code breakage with 2.074
On Wednesday, May 10, 2017 12:06:40 Ali Çehreli via Digitalmars-d wrote: > On 05/10/2017 11:49 AM, Jonathan M Davis via Digitalmars-d wrote: > > On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote: > >> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote: > >> > After upgrading the compiler, I get a warning that using a > > pointer as a > > >> > condition is deprecated. > > > > I think that that's the one that Andrei and Vladimir didn't like, > > because > > they actually used the conversion to bool correctly in their code a > > bunch > > (whereas most everyone else thought that it was too error prone), and > > the > > deprecation ended up being removed. > > > > - Jonathan M Davis > > Bummer for H. S. Teoh I guess... :/ > > Although I prefer explicit over implicit in most cases, I've never > graduated from if(p) and still using it happily. :) The big problems is dynamic arrays, not pointers, which was what I thought that H. S. Teoh was talking about (apparently, I read over what he said too quickly). I don't know about deprecations with pointers and if statements, and I use pointers sparingly enough in D that I don't know how long it would be before I'd notice if it _were_ deprecated. But with dynamic arrays, it checks for null, not for empty, and a bunch of folks tend to assume that it checks for empty. Using dynamic arrays directly in if conditions is what had been deprecated (on the theory that it was too error-prone) and what Andrei and Vladimir were unhappy about. - Jonathan M Davis
Re: Thoughts on some code breakage with 2.074
On 05/10/2017 11:49 AM, Jonathan M Davis via Digitalmars-d wrote: > On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote: >> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote: >> > After upgrading the compiler, I get a warning that using a pointer as a >> > condition is deprecated. > I think that that's the one that Andrei and Vladimir didn't like, because > they actually used the conversion to bool correctly in their code a bunch > (whereas most everyone else thought that it was too error prone), and the > deprecation ended up being removed. > > - Jonathan M Davis Bummer for H. S. Teoh I guess... :/ Although I prefer explicit over implicit in most cases, I've never graduated from if(p) and still using it happily. :) Ali
Re: Thoughts on some code breakage with 2.074
On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote:
> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
> > I even appreciate breakages that eventually force me to write more
> >
> > readable code! A not-so-recent example:
> >/* Used to work, oh, I forget which version now, but it used to
> >
> > * work: */
> >
> >MyType* ptr = ...;
> >if (someCondition && ptr) { ... }
> >
> > After upgrading the compiler, I get a warning that using a pointer as a
> > condition is deprecated. At first I was mildly annoyed... but then to
> >
> > make the warning go away, I wrote this instead:
> >/* Look, ma! Self-documenting, readable code! */
> >MyType* ptr = ...;
> >if (someCondition && ptr !is null) { ... }
>
> Can you show an example please. I don't see this being required by
> 2.074.0 (compiled with -w -de).
I think that that's the one that Andrei and Vladimir didn't like, because
they actually used the conversion to bool correctly in their code a bunch
(whereas most everyone else thought that it was too error prone), and the
deprecation ended up being removed.
- Jonathan M Davis
Re: Thoughts on some code breakage with 2.074
On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
> I even appreciate breakages that eventually force me to write more
> readable code! A not-so-recent example:
>
>/* Used to work, oh, I forget which version now, but it used to
> * work: */
>MyType* ptr = ...;
>if (someCondition && ptr) { ... }
>
> After upgrading the compiler, I get a warning that using a pointer as a
> condition is deprecated. At first I was mildly annoyed... but then to
> make the warning go away, I wrote this instead:
>
>/* Look, ma! Self-documenting, readable code! */
>MyType* ptr = ...;
>if (someCondition && ptr !is null) { ... }
Can you show an example please. I don't see this being required by
2.074.0 (compiled with -w -de).
Thank you,
Ali
Re: Thoughts on some code breakage with 2.074
On Wed, May 10, 2017 at 03:19:20AM +0200, Adam Wilson via Digitalmars-d wrote: [...] > Either way all I hear about is corp users not liking breaking changes. > That has been demonstrated as a false concern time and time again. > > If it's a matter of unmaintained libraries, those libraries probably > have bigger problems than breaking compiler changes, fork and upgrade > them or write your own. Because those have always been the only two > choices you've ever had in practice anyways. Telling the world that we > can't make breaking changes to the compiler because it might break an > unmaintained library is irrational position and extreme position to > take. It will *not* win us hearts and minds. > > Let's stop hiding behind our misplaced fears over corp-users and > unmaintained libraries so that we can start improving D for everyone > who is using it today. [...] +1. Please let's not go down the same path that led C++ to become what it is today: an overly complex language that almost nobody fully understands (and even fewer can write correct code in), yet still suffering under the weight of design mistakes of decades ago. But in spite of all that, it's, oh, backward-compatible! How wonderful, I can still compile my horribly-broken, memory-leaking, pointer-bug-infested excuse for code that I wrote when I was still in college! Isn't that great? Oh wait, it just segfaulted. No biggie, I can fix that easily ... give gimme a minute... uh... um... OK, WHAT has changed since the 90's that I can't do *this* anymore? (5 hours later) I give up, this code is useless. Why does C++ still bother supporting this crappy excuse for code after 2 decades?! T -- Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art. -- Tom Stoppard
Re: Thoughts on some code breakage with 2.074
On 5/9/17 20:23, Patrick Schluter wrote: On Tuesday, 9 May 2017 at 17:34:48 UTC, H. S. Teoh wrote: On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via Digitalmars-d wrote: > [...] [...] [...] [...] I don't represent any company, but I have to also say that I *appreciate* breaking changes that reveal latent bugs in my code. In fact, I even appreciate breakages that eventually force me to write more readable code! A not-so-recent example: [...] The code breakage annoyance has more to do with 3rd party libraries not very actively maintained than with active codebases imho. *cough* Umm, I think that's a false pointer. If it's not actively maintained, should you really be relying on it? Where I work, current maintenance is one of the first questions we ask, followed immediately by determining whether or not we are able to maintain it ourselves should it go unmaintained. If you're going to take on maintenance yourself, the library is already missing features and you're responsible for fixing it's existing implementation bugs anyways, might as well do the work of upgrading it while you're at it. This is the point of Open Source, we have the opportunity to take unmaintained code and start maintaining it again. Either way all I hear about is corp users not liking breaking changes. That has been demonstrated as a false concern time and time again. If it's a matter of unmaintained libraries, those libraries probably have bigger problems than breaking compiler changes, fork and upgrade them or write your own. Because those have always been the only two choices you've ever had in practice anyways. Telling the world that we can't make breaking changes to the compiler because it might break an unmaintained library is irrational position and extreme position to take. It will *not* win us hearts and minds. Let's stop hiding behind our misplaced fears over corp-users and unmaintained libraries so that we can start improving D for everyone who is using it today. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Thoughts on some code breakage with 2.074
On Tuesday, 9 May 2017 at 17:34:48 UTC, H. S. Teoh wrote: On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via Digitalmars-d wrote: > [...] [...] [...] [...] I don't represent any company, but I have to also say that I *appreciate* breaking changes that reveal latent bugs in my code. In fact, I even appreciate breakages that eventually force me to write more readable code! A not-so-recent example: [...] The code breakage annoyance has more to do with 3rd party libraries not very actively maintained than with active codebases imho.
Re: Thoughts on some code breakage with 2.074
On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via Digitalmars-d wrote:
> On 5/8/17 20:33, Brian Schott wrote:
> > Recently the EMSI data department upgraded the compiler we use to
> > build our data processing code to 2.074. This caused several of the
> > thousands of processes to die with signal 8 (floating point
> > exceptions). This was caused by the fix to issue 17243.
> >
> > This is a good thing. We need more breaking changes like this.
[...]
> WUT.
>
> All I hear on these forums is the abject terror of breaking changes
> making companies run screaming from D. You mean to say that companies
> don't actually mind breaking changes if it solves long-standing
> issues.
>
> I'm shocked. SHOCKED I SAY!
>
> ;-)
>
> Can we PLEASE get more of this? I'm not saying up-end the language,
> but let's solve some problems. I doubt our corporate users will be
> very angry. I suspect that most reactions will fall between "minor
> irritation" and this one.
>
> /me looks sideways at shared
[...]
I don't represent any company, but I have to also say that I
*appreciate* breaking changes that reveal latent bugs in my code. In
fact, I even appreciate breakages that eventually force me to write more
readable code! A not-so-recent example:
/* Used to work, oh, I forget which version now, but it used to
* work: */
MyType* ptr = ...;
if (someCondition && ptr) { ... }
After upgrading the compiler, I get a warning that using a pointer as a
condition is deprecated. At first I was mildly annoyed... but then to
make the warning go away, I wrote this instead:
/* Look, ma! Self-documenting, readable code! */
MyType* ptr = ...;
if (someCondition && ptr !is null) { ... }
Much more readable, and makes intent so much clearer. Eventually I was
very happy this supposedly "big bad" breaking change was made.
I wish Walter & Andrei & gang would introduce this sort of breakages
more often. They will both improve the language and impress users whose
code we are so afraid of breaking (I'm still not sure why).
T
--
Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Re: Thoughts on some code breakage with 2.074
On Tuesday, 9 May 2017 at 12:13:34 UTC, Adam Wilson wrote: Can we PLEASE get more of this? I'm not saying up-end the language, but let's solve some problems. I doubt our corporate users will be very angry. I suspect that most reactions will fall between "minor irritation" and this one. /me looks sideways at shared Here is more of this. Writing industry D code I *love* breaking changes that reveal bugs in the code base. A while ago I suggested changing cast(bool) semantics of floating-point types so that assert(x) fails if x is NaN (https://issues.dlang.org/show_bug.cgi?id=13489). It was rejected because it could break existing code and surprise C/C++ programmers (although the point of NaN is to surprise you IMHO). I wonder what the ratio of valid to buggy code is that would break with this change. At least I enjoy it if my buggy code breaks.
Re: Thoughts on some code breakage with 2.074
On 5/8/17 20:33, Brian Schott wrote: Recently the EMSI data department upgraded the compiler we use to build our data processing code to 2.074. This caused several of the thousands of processes to die with signal 8 (floating point exceptions). This was caused by the fix to issue 17243. This is a good thing. We need more breaking changes like this. Now that the floating point exceptions are properly enabled we were able to track down some issues that were being silently ignored. WUT. All I hear on these forums is the abject terror of breaking changes making companies run screaming from D. You mean to say that companies don't actually mind breaking changes if it solves long-standing issues. I'm shocked. SHOCKED I SAY! ;-) Can we PLEASE get more of this? I'm not saying up-end the language, but let's solve some problems. I doubt our corporate users will be very angry. I suspect that most reactions will fall between "minor irritation" and this one. /me looks sideways at shared -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Thoughts on some code breakage with 2.074
Recently the EMSI data department upgraded the compiler we use to build our data processing code to 2.074. This caused several of the thousands of processes to die with signal 8 (floating point exceptions). This was caused by the fix to issue 17243. This is a good thing. We need more breaking changes like this. Now that the floating point exceptions are properly enabled we were able to track down some issues that were being silently ignored.
