Anyone interested in the AGM can watch it at the following link. You can leave feedback there, in IRC, or in Discord.

https://youtu.be/cpTAtiboIDs

On Saturday, 11 May 2019 at 07:53:36 UTC, Mike Parker wrote:
> Anyone interested in the AGM can watch it at the following link. You can leave feedback there, in IRC, or in Discord.
>
> https://youtu.be/cpTAtiboIDs

Regarding the discussion of how bool is handled...

> It's a one bit integer so it should behave like a one bit integer
https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s

Wouldn't entirely say that, someone already pointed out the ++ operator but it does not behave like an integer in other respects either.

It does not overflow the same way an integer does, max + 1 -> 0. A 1-bit integer can only hold two values, 0/1. 1 + 1 should equal 0, but instead it equals 1. It is already a special case. Converting any integer will result in the bool being set to 1, the only time it isn't is when the integer is zero. Not like a 1-bit integer would.

    writeln( cast(ubyte) (ubyte.max + 1) );  // 0
    writeln( cast(ushort)(ushort.max + 1) ); // 0
    writeln( cast(uint)  (uint.max + 1) );   // 0
    writeln( cast(ulong) (ulong.max + 1) );  // 0
    writeln( cast(bool)  (bool.max + 1) );   // 1 (true)



> Maybe you got too many overloads and what are you trying to do with those overloads that it would matter that it called a different overload
https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h20m42s

I've seen it a few times, if you just a simple variant or some sort of generic script type to be used. You don't need "too many overloads" it literally takes 2, the minimum number of overloads for there to be an overload.


struct SomeVariantOrScriptTypeGeneric {
    enum Type { Bool, Long, }

    Type type;
    union { bool bool_; long long_; }

    this( bool ) { type = Type.Bool; }
    this( long ) { type = Type.Long; }
}

enum int a = 1;
enum int b = 2;

SomeVariantOrScriptTypeGeneric v = b - a; // type == Bool

Sure it is convenient to have some properties of bool also be similar to an integer, but it can definitely not be swapped in to be used like a 1-bit integer and there are already plenty of special rules for it.

On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:

> Regarding the discussion of how bool is handled...
>
>> It's a one bit integer so it should behave like a one bit integer
> https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s

I think Walter is conflating how bool is stored in memory with its semantics.  I'm currently considering using D's rich modeling features to create a new boolean type that behaves more like a boolean and less like a bit.  But it's unfortunate and disappointing we have to resort to something like that.

Mike

On 5/11/19 10:27 PM, Mike Franklin wrote:
> On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:
> 
>> Regarding the discussion of how bool is handled...
>>
>>> It's a one bit integer so it should behave like a one bit integer
>> https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s
> 
> I think Walter is conflating how bool is stored in memory with its semantics.

I find this tends to be an unfortunately *very easy* trap to fall into for programmers highly-experienced in low-level work: the conflation of abstraction vs implementation. This conflation is something they're more accustomed to, more comfortable with, and more tolerant of, than other programmers.

The real key here is this:

Do we have 'bool' because a 1-bit integer is useful, or do we have 'bool' because a "true vs false" abstraction is useful?

The answer to that dictates the correct semantics.

> I'm currently considering using D's rich modeling features to create a new boolean type that behaves more like a boolean and less like a bit.  But it's unfortunate and disappointing we have to resort to something like that.

Please do! Way I figure, it'll either work great and be a fantastic tool to have, or at the very *worst*, if there turns out to be any downsides to using it (vs a well-made built-in bool), then it will still serve to help root out any areas where D can improve its in-library modeling capabilities.

On 5/11/2019 7:27 PM, Mike Franklin wrote:
> I think Walter is conflating how bool is stored in memory with its semantics.

That's exactly what I'm deliberately doing.

> I'm currently considering using D's rich modeling features to create a new boolean type that behaves more like a boolean and less like a bit.  But it's unfortunate and disappointing we have to resort to something like that.

I understand. Every programmer, sooner or later, decides to step up and take a swing at inventing boolean. (I have too - did you know that D used to have a `bit` builtin type?) The programming landscape is littered with the corpses of one after another. Phobos has multiple ones - RefCountedAutoInitialize .yes and .no, and even a struct Yes and a struct No. std.bitmanip has an enum A{True,False}. std.json has enum E{True=true}. std.typecons has the bizarre enum issue10647_isAlwaysTrue=true;. (One wonders what would happen if it was set to false. Would it cause a rip in the fabric of space-time? I dare not experiment with that!)

The C++ Committee currently is fiercely debating adding a "Boolean" construct in one of the longest threads I've ever seen. One of their problems is it conflicts with the endless "Boolean" types added to existing C++ code, along with every variation "Bool", "Bool", "boolean", etc.

All this effort strongly implies that there's no such thing as a satisfactory bool type. Will you succeed where 10,000 other programmers have failed? Seems unlikely. But I doubt I will dissuade you from trying.

So what does work reasonably? Treating it like a small integer. We know what the various integer semantics are, and it fits right in with that. I know the operator ++ difference, and it is my fault that I succumbed to a moment of boolean madness and allowed that in. (++ on D bool is saturation arithmetic, unlike the overflow semantics in every other integer type. It is a mistake, please don't use that as justification for adding more quirky behaviors.)

On a final note, C++ added a std::vector<bool> special case, which works unlike any other vector type. Years of experience have shown that to have been a mistake, just like all the others, and it is widely derided as a complete failure.

On 5/12/19 1:43 AM, Walter Bright wrote:
> On 5/11/2019 7:27 PM, Mike Franklin wrote:
>> I think Walter is conflating how bool is stored in memory with its semantics.
> 
> That's exactly what I'm deliberately doing.
> 
>> I'm currently considering using D's rich modeling features to create a new boolean type that behaves more like a boolean and less like a bit.  But it's unfortunate and disappointing we have to resort to something like that.
> 
> I understand. Every programmer, sooner or later, decides to step up and take a swing at inventing boolean.

No, not really. Only the ones using languages that either lack a high-level notion of boolean or conflate it with an integer.

> (I have too - did you know that D used to have a `bit` builtin type?)

Yes. I remember those days. It was renamed "bool" to better reflect its actual real-world use-cases.

> The programming landscape is littered with the corpses of one after another.

Only in languages that either lack a built-in bool or conflate it with integers.

> Phobos has multiple ones - RefCountedAutoInitialize .yes and .no,

Basically the same as the "struct Yes and No" below...(and if it's somehow *diffe rent* from the normal struct yes/no, then that sounds like a very clear Phobos failing...)

> and even a struct Yes and a struct No.

Which Andrei *intentionally* created as a library-based substitute for *named arguments*, if you'll recall without contorting the true history.

> std.bitmanip has an enum A{True,False}. std.json has enum E{True=true}. std.typecons has the bizarre enum issue10647_isAlwaysTrue=true;.
> (One wonders what would happen if it was
> set to false. Would it cause a rip in the fabric of space-time? I dare
> not experiment with that!)


Yet more examples of how D either sucks at bool and/or needs named arguments. Thus, completely failing to provide support for the patently false "Every programmer, sooner or later, decides to [...] take a swing at inventing boolean" claim.

> The C++ Committee currently is fiercely debating adding a "Boolean" construct in one of the longest threads I've ever seen. One of their problems is it conflicts with the endless "Boolean" types added to existing C++ code, along with every variation "Bool", "Bool", "boolean", etc.

Alex, I'll take "Languages which conflate boolean with integer" for $500, please...

Daily double!!!!

> All this effort strongly implies that there's no such thing as a satisfactory bool type.

Correction:

All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers*

> On a final note, C++ added a std::vector<bool> special case, which works unlike any other vector type. Years of experience have shown that to have been a mistake, just like all the others, and it is widely derided as a complete failure.

Ohh, I see..So...you're saying that special-casing an *aggregate* of a type **cough**char**cough** is bad. And furthermore, that in turn, demonstrates that the element type of a special-cased aggregate must therefore be unsound as well.

Or is it that applying correct semantics to a type's aggregate without also applying them to the type itself is a recipe for disaster?

On Sunday, 12 May 2019 at 05:43:01 UTC, Walter Bright wrote:
> On 5/11/2019 7:27 PM, Mike Franklin wrote:
> I understand. Every programmer, sooner or later, decides to step up and take a swing at inventing boolean. (I have too - did you know that D used to have a `bit` builtin type?)

Yes, D did have a bit type that was removed since it required special casing for something that didn't provide much of a benefit.

> The programming landscape is littered with the corpses of one after another.

You say the programming landscape, yet give very limited examples. It would help to give examples in languages that did not have a hindered boolean type. In languages with a non-hindered boolean (e.g. Java) I've only ever seen custom booleans for overloading or to flag intent when named arguments are unsupported.

> Phobos has multiple ones

Well... yes, this is Phobos; Phobos is in need of a cleanup.

> RefCountedAutoInitialize .yes and .no

Something like this is probably a remnant of code made before std.typecons.Flag. It shouldn't have gotten into Phobos (regardless of if it was before or after std.typecons.Flag).

> and even a struct Yes and a struct No.

The structs Flag, Yes, and No should not be considered by themselves as they are all apart of the same concept. The Flag concept is to force a caller to explicitly state what true/false mean. This is desired due to the lack of named arguments in D.

> std.bitmanip has an enum A{True,False}. std.json has enum E{True=true}.

In unittests they do. The std.bitmanip is most likely overzealously testing something (1-bit sized enum?). The std.json one is obviously testing if an enum with an underlying boolean value is correctly converted.

> std.typecons has the bizarre enum issue10647_isAlwaysTrue=true;.

Yes, that is bizarre. Considering its a enum constant of type bool, this doesn't pertain to custom boolean types.

> The C++ Committee currently is fiercely debating adding a "Boolean" construct in one of the longest threads I've ever seen. One of their problems is it conflicts with the endless "Boolean" types added to existing C++ code, along with every variation "Bool", "Bool", "boolean", etc.
>
> All this effort strongly implies that there's no such thing as a satisfactory bool type.

No, this implies C++ had a boolean type that was lacking; which it *severely* is in type safety.

There are multiple booleans in C++ because programmers are not going to unite on one *non-standard* boolean type. Even if the committee added one, it will take years for the damage to be undone (if ever).

> Will you succeed where 10,000 other programmers have failed?
> Seems unlikely. But I doubt I will dissuade you from trying.

Well other than the overstatement on reinventing the boolean; I do agree here that success is unlikely, but not for the same reason. A custom boolean type will be used infrequently (I'm certainly not depending on a dub package just for a boolean type), will have to be imported in *every* file it is used in, and will inevitably fracture whenever someone copies the code to their codebase.

> So what does work reasonably?
> Treating it like a small integer.

So mixing the concepts of true/false and numerical data is "reasonable". I'll have to remember that if I ever have a true/false test; 1's and 0's are quicker to write than T's and F's.

Jokes aside, I have yet to see how making it a "small integer" improves this supposed reinventing-the-bool-wheel problem or makes it anymore useful than a normal boolean. In fact, it seems more-so like you've made a oval wheel: technically functional but not really.

> I know the operator ++ difference, and it is my fault that I succumbed to a moment of boolean madness and allowed that in. (++ on D bool is saturation arithmetic, unlike the overflow semantics in every other integer type. It is a mistake, please don't use that as justification for adding more quirky behaviors.)

I don't have to justify other quirky behavior with ++ being saturated arithmetic because you said:

> Treating it like a small integer.

If bool is going to be a 1-bit integer with saturated arithmetic semantics, then it should act like one. +=, -=, *=, ^^=, /=, and %= should be allowed as it is a "small integer". Sure /= and %= would largely be a divide-by-zero operation, but at least bool would be the type unsafe "integer" it is suppose to be.

> We know what the various integer semantics are, and it fits right in with that.

I have yet to see where bool fits into integer semantics reasonably without causing problems and annoyances (as well as having just generally weird behavior).

> On a final note, C++ added a std::vector<bool> special case, which works unlike any other vector type. Years of experience have shown that to have been a mistake, just like all the others, and it is widely derided as a complete failure.

That isn't a fault of bool by any means, that is the fault of making an unnecessary special case that sometimes acts different from every other case.


The real question to look at here is what Nick said:
> Do we have 'bool' because a 1-bit integer is useful, or do we have
> 'bool' because a "true vs false" abstraction is useful?

The answer to that, is because a "true vs false" abstraction is useful. A 1-bit integer provides no real benefit: I could still use a byte and get pretty much the same behavior (type unsafety and all!). I could even do like a lot of C/C++ code I've seen and use int.

This is the crux of the argument: *How* does making bool an integer add to the language? We have examples of how making bool *not* an integer adds to the language, mainly in type safety; we still don't have examples of how making it an integer adds to the language.

On 5/12/19 11:27 AM, Isaac S. wrote:
> This is the crux of the argument: *How* does making bool an integer add to the language?

The crux of the argument is there was a D Improvement Proposal on a small language change, and it was rejected.

Rejected D Improvement Proposals on small matters that D language's leader thinks strongly about should allow everybody to move on to larger, better things.

We are unable to, and should not be required to, provide argumentation when making a decision on a DIP that will be to the satisfaction of everybody involved. Of course, pressure does exist on making the right decision and on framing it properly; otherwise, one poor decision after another, we end up with a bad language that people will not want to use.

Walter's last argument in this thread is poorly made and has several factual errors. He's traveling and with a bunch of stuff going on right after DConf. But the larger point is it doesn't matter - the DIP was looked at and rejected (I should add I concurred with the decision and still do). 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.

On Sunday, 12 May 2019 at 10:58:49 UTC, Andrei Alexandrescu wrote:
> Rejected D Improvement Proposals on small matters that D language's leader thinks strongly about should allow everybody to move on to larger, better things.
>
> We are unable to, and should not be required to, provide argumentation when making a decision on a DIP that will be to the satisfaction of everybody involved.

No no no, no. No.

You have rejected the DIP to the annoyance of the community, That is fine. You have a decision making process.

However in this case the community consensus is that the chain of reasoning you have used to arrive at your decision is wrong.

> Of course, pressure does exist on making the right decision and on framing it properly;

Indeed, you should be making the right decisions _ for the right reasons_. I note that this is uncorrelated with wether or not we want the feature, c.f. refcounting before we had copy constructors (wanted it but couldn't have it because memory safety reasons) and opPostMove (didn't want to have to have it but e.g. couldn't interface with GCC's std::string).

> otherwise, one poor decision after another, we end up with a bad language that people will not want to use.

Yes, but for the completely opposite reason. If the community believe the reasoning you provide for the decision you have made is wrong then we will end up with a language we not as satisfied with.

> [Because reasons] that all is wasted time.
>
> There's a bunch of big rocks to move.

Jut because we have a bunch of other large problems does not mean that we shouldn't be fixing other problems in the language that you happen to disagree with.

On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:

> Sure it is convenient to have some properties of bool also be similar to an integer, but it can definitely not be swapped in to be used like a 1-bit integer and there are already plenty of special rules for it.

Thanks for that analysis.  So we have a bool that is neither a boolean nor a bit.  That stinks.

Walter and Andrei have made their decision, so it doesn't look like we'll be able to do anything about it unless maybe Atila feels that it's something that needs to be addressed.

Anyway, I'm of the mind that the language should just provide a set of powerful, composable primitives and delegate course-grained features and specializations to the library.  I've been re-imagining druntime and phobos at lot lately and I'm more confident that we can define a wrapper around `bool` to give it proper boolean semantics.  Maybe, if Walter would support it, we could then fix bool to make it a proper `bit`.  Then in the library `alias bit = bool;` and live happily ever after.

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.

Mike