On 5/12/19 10:17 PM, Exil wrote:
> On Sunday, 12 May 2019 at 10:58:49 UTC, Andrei Alexandrescu wrote:
>> Bringing it up over and over again, like a perennial fight in a marriage, with the hope of finally convincing the spouse on the wrongness of their views - that all is wasted time.
>>
>> There's a bunch of big rocks to move.
> 
> I take it from this response you mean, once a DIP is rejected it would never be looked at again, even if a second DIP was created for the same purpose with different arguments?

A new DIP argued differently would be considered. If that's not in the official DIP guidelines, it should.

On Mon, May 13, 2019 at 07:16:04AM -0400, Andrei Alexandrescu via Digitalmars-d-announce wrote:
> On 5/12/19 11:46 PM, H. S. Teoh wrote:
> > On Sun, May 12, 2019 at 01:20:16PM +0000, Mike Franklin via Digitalmars-d-announce wrote: [...]
> > > If anyone's looking for a challenge, I welcome them to propose a new `Bool` type (note the capital B) for inclusion in my new library.
> > [...]
> > 
> > As long as && and || continue to evaluate to a 1-bit integer, all library efforts to implement Bool will be futile.
> 
> When writing std.typecons.Ternary I thought of overloading opBinary for | and & to take a lazy argument on the right. I forgot why I ended up not doing it (I think it was because of code generation issues). This is something that could be made to work.

The problem is that && and || cannot be overloaded (and for very good reasons -- it would open the door to C++-style egregious operator overload abuse), and the alternatives & and | have the wrong precedence, so you wouldn't be able to write boolean expressions with Bool naturally the way you could with the built-in bool type. It would not be a drop-in replacement and you would have to rewrite every single boolean expression to use Bool instead, and that with a high chance of introducing subtle errors because of the different precedence of & and |.

Boolean expressions and the associated boolean type is one of the things that should be baked into the language (it'd be a mess otherwise), but that also means that if the language doesn't get it right you have no recourse.


T

-- 
Too many people have open minds but closed eyes.

On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky (Abscissa) wrote:
> All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers*

FWIW I write C# for food and to me D bool is better than C# bool. Didn't watch, but if it's about the DIP I think of, its rationale was overload rules, Walter said he's not opposed to tune them. It was derailed into discussion about strong bool?

On Tuesday, 14 May 2019 at 15:40:19 UTC, Kagamin wrote:
> On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky (Abscissa) wrote:
>> All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers*
>
> FWIW I write C# for food and to me D bool is better than C# bool. Didn't watch, but if it's about the DIP I think of, its rationale was overload rules, Walter said he's not opposed to tune them. It was derailed into discussion about strong bool?

At the time the DIP was written, we didn't know Walter conflates bool and bit.  Now that we do a new DIP could argue differently that bool and bit should not be conflated and that that would also fix the overload issues.

Mike

On 5/14/19 8:47 PM, Mike Franklin wrote:
> On Tuesday, 14 May 2019 at 15:40:19 UTC, Kagamin wrote:
>> On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky (Abscissa) wrote:
>>> All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers*
>>
>> FWIW I write C# for food and to me D bool is better than C# bool. Didn't watch, but if it's about the DIP I think of, its rationale was overload rules, Walter said he's not opposed to tune them. It was derailed into discussion about strong bool?
> 
> At the time the DIP was written, we didn't know Walter conflates bool and bit.  Now that we do a new DIP could argue differently that bool and bit should not be conflated and that that would also fix the overload issues.

There are many clowny things in D, of which bool is at best somewhere beyond the radar. I suggest investing time * expertise in the larger ones.

On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu wrote:

> There are many clowny things in D, of which bool is at best somewhere beyond the radar. I suggest investing time * expertise in the larger ones.

Once again, I disagree with what you think is important.  `bool` is a fundamental type on which many things in D depend.  If it doesn't work right, neither will the features that depend on it.  But, that's your decision, and there's little to nothing we can do about it, so I guess we just accept the fact that D is clowny and deal with it; it's what so many of us, so often do.

On 5/14/19 2:00 AM, Mike Franklin wrote:
> On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu wrote:
> 
>> There are many clowny things in D, of which bool is at best somewhere beyond the radar. I suggest investing time * expertise in the larger ones.
> 
> Once again, I disagree with what you think is important.  `bool` is a fundamental type on which many things in D depend.

I'd be hard pressed to find my style cramped by D's bool.

> If it doesn't work right, neither will the features that depend on it.
> But, that's your decision, and there's little to nothing we can do about it, so I guess we just accept the fact that D is clowny and deal with it; it's what so many of us, so often do.

(At any rate, going forward it's not me who needs convincing.) In my humble opinion, any language would have minor quirks, and a landmark of good engineering is attacking the right problems. That we even discuss just how bad bool is while we have no done deals for safety, reference counting, shared, package distribution/versioning, pay-as-you-go runtime, collections, ..., is a fascinating puzzle.

On Wednesday, 15 May 2019 at 01:15:43 UTC, Andrei Alexandrescu wrote:

> That we even discuss just how bad bool is while we have no done deals for safety, reference counting, shared, package distribution/versioning, pay-as-you-go runtime, collections, ..., is a fascinating puzzle.

It can all be done simultaneously.  I'm working on a couple of those items along with a few others simultaneously.

I can't dedicate all my energy to one item, though.  I often need to work on something, and then step away from it for a while.  I then work on something else, and when I get back to the first item, I see with greater clarity.

Also, sometimes I have to wait for others.  For example, I submit a DIP, and I need to wait for it to go through the process.  While that's happening I work on something else.

And then, sometimes, I just don't have many cycles left at the end of the day.  But I still find it therapeutic to work on trivial things; it relaxes me.

There's no reason any and all work that moves D forward shouldn't be encouraged.  If bool is clowny, and someone's willing to do something about it, why discourage them from doing so?

Mike

On 5/14/2019 6:34 PM, Mike Franklin wrote:
> If bool is clowny, and someone's willing to do something about it, why discourage them from doing so?

Because core language changes necessarily consume a lot of other peoples' time, not just yours. This extends well beyond just the core developers - it will break existing code, have switches to alter the behavior, add complexity to the spec and the documentation, etc.

On Tuesday, May 14, 2019 7:15:43 PM MDT Andrei Alexandrescu via Digitalmars- d-announce wrote:
> On 5/14/19 2:00 AM, Mike Franklin wrote:
> > On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu wrote:
> >> There are many clowny things in D, of which bool is at best somewhere beyond the radar. I suggest investing time * expertise in the larger ones.
> >
> > Once again, I disagree with what you think is important.  `bool` is a fundamental type on which many things in D depend.
>
> I'd be hard pressed to find my style cramped by D's bool.

There are well-known issues where the current behavior causes bugs, and personally, I'd prefer that the DIP have been accepted, but I have to agree that it isn't a big problem. It's basically just one of those small warts in the language that it would be nice to have fixed, and a number of the people who come to D looking for a better language seem to want it to be absolutely perfect and want every minor issue fixed. Unfortunately, while that would be nice, it really isn't practical. Every language has warts, and if something like this were the worst issue that D had, then we'd be _very_ well off.

> > If it doesn't work
> > right, neither will the features that depend on it.
> > But, that's your
> > decision, and there's little to nothing we can do about it, so I guess
> > we just accept the fact that D is clowny and deal with it; it's what so
> > many of us, so often do.
>
> (At any rate, going forward it's not me who needs convincing.) In my humble opinion, any language would have minor quirks, and a landmark of good engineering is attacking the right problems. That we even discuss just how bad bool is while we have no done deals for safety, reference counting, shared, package distribution/versioning, pay-as-you-go runtime, collections, ..., is a fascinating puzzle.

I think that in this case, it's a combination of it being a form of bikeshedding (since the DIP is on an issue that's easy to understand and have an opinion on) and that a DIP was written up for it and rejected. So, some of the folks who disagree with the decison want to debate it and somehow get a different decision.

In general though, I think that the problem with tackling harder problems like ref-counting or shared or whatever is simply that it takes a lot more time and effort, and most people either don't have that kind of time or don't want to spend it on a hard problem (assuming that they even have enough expertise to do so in the first place). It's easy to point out and debate a small problem like how bool is treated like an integral type when many of us don't think that that it should ever be treated as an integral type, but it's much harder and more time-consuming to tackle the larger problems. So, unfortunately, the harder problems are too frequently left by the wayside. And as I'm sure you can attest to, even those of us who might consider tackling the harder problems have enough on our plates already that even if an issue is on our TODO list, it can easily be drowned out by other issues.

Regardless, as a group, we do need to find ways to better tackle some of our larger, more pressing problems. The small stuff does matter, and it's easier to tackle, but if we're consistently trying to solve the small problems without tackling the larger ones, then we have a serious problem.

- Jonathan M Davis