www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DConf 2019 AGM Livestream

reply Mike Parker <aldacron gmail.com> writes:
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
May 11 2019
next sibling parent reply Exil <Exil gmall.com> writes:
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.
May 11 2019
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 11 2019
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
May 11 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 11 2019
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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?
May 11 2019
parent reply Kagamin <spam here.lot> writes:
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*



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?
May 14 2019
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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*



 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
May 14 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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*



 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.
May 14 2019
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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.
May 14 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
May 14 2019
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 14 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 14 2019
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
May 15 2019
prev sibling next sibling parent reply Isaac S. <spam-no-reply-isaac outlook.com> writes:
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.
May 12 2019
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
May 12 2019
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
May 12 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/12/19 1:34 PM, Nicholas Wilson wrote:

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


It's a simple enough matter to be understood, and reasonable to assume 
Walter is not missing any important facts or details. Poking holes in 
his explanations is, I confess, attractive, but ultimately are about 
debate skills rather than technical. I do agree that the way 
explanations on DIP decisions go could and should be improved a lot.
May 12 2019
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, May 12, 2019 8:50:33 AM MDT Andrei Alexandrescu via Digitalmars-
d-announce wrote:

 On 5/12/19 1:34 PM, Nicholas Wilson wrote:

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


 It's a simple enough matter to be understood, and reasonable to assume
 Walter is not missing any important facts or details. Poking holes in
 his explanations is, I confess, attractive, but ultimately are about
 debate skills rather than technical. I do agree that the way
 explanations on DIP decisions go could and should be improved a lot.


Really, what it comes down to is that Walter has a very different view on
what a bool is and what it means than many in the community. His explanation
makes it clear why he made the decision that he made. Many of us don't agree
with the decision, because we view bool and its purpose very differently,
but unless someone has an argument that would actually convince Walter to
look at bools differently, it's a pretty pointless discussion. It's
frustrating, and many of us do think that D is worse than it could be
because of the decision, but ultimately, Walter is the one in charge, and
that's just how it goes. This just highlights how the language is ultimately
controlled by the one or two people at the top and not by the community at
large. It's not a democracy, which on the whole is a good thing. If all
language decisions were made by majority vote, the language would be an
utter mess. But that does have the downside that sometimes something that
many people want doesn't happen, because those in charge don't agree. Such
is life. Fortunately, in the grand scheme of things, while this issue does
matter, it's still much smaller than almost all of the issues that we have
to worry about and consider having DIPs for.

Personally, I'm not at all happy that this DIP was rejected, but I think
that continued debate on it is a waste of everyone's time.

- Jonathan M Davis
May 12 2019
parent Jon Degenhardt <jond noreply.com> writes:
On Sunday, 12 May 2019 at 17:08:49 UTC, Jonathan M Davis wrote:

 ... snip ...
 Fortunately, in the grand scheme of things, while this issue 
 does matter, it's still much smaller than almost all of the 
 issues that we have to worry about and consider having DIPs for.

 Personally, I'm not at all happy that this DIP was rejected, 
 but I think that continued debate on it is a waste of 
 everyone's time.


Agreed. I too have never liked numeric values equated to 
true/false, in any programming language. However, it is very 
common. And, relative to other the big ticket items on the table, 
of minor importance. Changing the current behavior won't 
materially affect the usability of D or its future. This is a 
case where the best course is to make a decision move on.

--Jon
May 12 2019
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 12 May 2019 at 14:50:33 UTC, Andrei Alexandrescu wrote:

 On 5/12/19 1:34 PM, Nicholas Wilson wrote:

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


 It's a simple enough matter to be understood, and reasonable to 
 assume Walter is not missing any important facts or details. 
 Poking holes in his explanations is, I confess, attractive, but 
 ultimately are about debate skills rather than technical. I do 
 agree that the way explanations on DIP decisions go could and 
 should be improved a lot.


Then let me rephrase my complaints as a question (to you, Walter 
and the community):

At what level of egregiousness of the degree to which the 
unanimous community consensus believes both your decision and 
chain of reasoning are fundamentally wrong, do we, the community, 
decide to reject your position completely and implement the 
community consensus?
May 12 2019
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, May 12, 2019 2:58:58 PM MDT Nicholas Wilson via Digitalmars-d-
announce wrote:

 On Sunday, 12 May 2019 at 14:50:33 UTC, Andrei Alexandrescu wrote:

 On 5/12/19 1:34 PM, Nicholas Wilson wrote:

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


 It's a simple enough matter to be understood, and reasonable to
 assume Walter is not missing any important facts or details.
 Poking holes in his explanations is, I confess, attractive, but
 ultimately are about debate skills rather than technical. I do
 agree that the way explanations on DIP decisions go could and
 should be improved a lot.


 Then let me rephrase my complaints as a question (to you, Walter
 and the community):

 At what level of egregiousness of the degree to which the
 unanimous community consensus believes both your decision and
 chain of reasoning are fundamentally wrong, do we, the community,
 decide to reject your position completely and implement the
 community consensus?


Anyone is free to fork the language at any time, but unless you're going to
try to get Walter to step down, he's in charge of D, and he has the final
say. It's obviously problematic if he makes a bad decison and no one can
convince him otherwise, but if you can't convince him of something, and
you're so convinced that he's wrong that you want to effectively take the
decision away from him, then that basically comes down to forking the
language or getting him to step down. The language and its implementation
are certainly a cooperative effort, but ultimately, it's not a democracy.
Walter is the one in charge, and it's his decision. He's chosen to share his
position on some level with Andrei (and now Atila), but it's his language.

Personally, I think that bool should never be treated as an integral value
rather than always treated as an integral value or partially treated as an
integral value. The current behavior is arguably a bad legacy from C/C++,
and it definitely causes bugs. So, I'm quite disappointed with the rejection
of this DIP. But I honestly don't think that this is a big enough issue to
effectively start discussing how or when we take the decision making power
away from Walter. Unless someone can come up with a way to convince Walter
to view bools differently (which I very much doubt is going to happen), I
think that it's quite clear that we're just going to have to learn to
continue to live with the status quo on this issue.

- Jonathan M Davis
May 12 2019
prev sibling parent reply Exil <Exil gmall.com> writes:
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?

So changes like this one should be reversed then? 
https://github.com/dlang/phobos/pull/5343

And isIntegral should also be updated to include bool? Where is 
the line drawn? Should it be treated like an integral only in the 
language but not in phobos?
May 12 2019
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
May 13 2019
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 12 May 2019 at 10:27:42 UTC, Isaac S. wrote:

 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.


I agree with you that bool should be kept separate from ints, but 
in low level programming on some RISC architectures where 
branching is expensive it brings significant performance benefits 
to do things like this:

x = a*(y<3) + b*(z>5);

This was a common trick for writing branch-free high performance 
code on SGI machines (MIPS based) in the 90s.

Not that D is used for this kind of performance oriented coding, 
but there are use cases related to low level programming that 
makes it reasonable. Although a cast is a good tradeoff.

(It is completely unreasonable for high level programming 
however.)
May 19 2019
prev sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Sunday, 12 May 2019 at 05:43:01 UTC, Walter Bright wrote:

 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.


If you succeed at implementing bool, nobody debates it. As such, 
the huge debates are intrinsically of people failing at 
implementing bool. A successful boolean implementation is 
invisible.


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


Yes, because it's clearly succeeding at avoiding huge forum 
debates...
May 13 2019
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 12 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. --
Napoleon Bonaparte
May 12 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
May 13 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
May 13 2019
prev sibling parent =?UTF-8?B?QXVyw6lsaWVu?= Plazzotta <thatsme gmail.com> writes:
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


Will there be a plan to revive the dip 1017 - add a Bottom type 
and submit a stronger proposal thanks to the Human Resource Fund?
May 12 2019