April 27, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
> On 4/27/2013 2:29 PM, Rob T wrote:
>> If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords?
>
> Because writing cast(bool)0 and cast(bool)1 is unappealing.
That cannot be the main reason. There must be a more fundamental reason for having true and false (which is inconsistent with ints) instead of 1b and 0b (which is consistent with ints).
--rt
|
April 27, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | On 4/27/2013 1:26 PM, kenji hara wrote:
> I don't have so much knowledge about C/C++ language spec, but for the issue case
> C++ makes "ambiguous error".
That's because C++ regards an implicit conversion of 1 to bool or long as having equal weight, and it has no further mechanism.
|
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 4/27/2013 3:58 PM, Walter Bright wrote:
> On 4/27/2013 1:26 PM, kenji hara wrote:
>> I don't have so much knowledge about C/C++ language spec, but for the issue case
>> C++ makes "ambiguous error".
>
> That's because C++ regards an implicit conversion of 1 to bool or long as having
> equal weight, and it has no further mechanism.
>
Note that the following is also ambiguous in C++:
void foo(bool b) { }
void foo(long l) { }
void main() {
foo(3);
}
|
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, April 27, 2013 14:52:31 Walter Bright wrote:
> On 4/27/2013 2:29 PM, Rob T wrote:
> > If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords?
> Because writing cast(bool)0 and cast(bool)1 is unappealing.
You'd only be forced to do that outside of conditions, as the cast is already inserted for you in conditions. And if you really need bool, one could argue that it doesn't make sense to be using integer literals anyway. We already have true and false if you really want a bool when deal with literals. I like being able to do while(1) because it's shorter, but it's not ultimately all that onerous to have to do while(true), and the casting in conditions takes care of that case anyway. In most cases, simply using a bool when you mean bool, and an int when you want an integral type solves the problem quite cleanly.
The main place that I can see that it makes sense to end up with casts to and from bool which might get annoying is if you're trying to use bools in arithmetic, and I honestly don't think that allowing implicit casts there is worth all of the other weirdness it causes in the language in general.
- Jonathan M Davis
|
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Maxim Fomin | On Saturday, April 27, 2013 06:19:29 Maxim Fomin wrote:
> On Friday, 26 April 2013 at 21:34:44 UTC, Walter Bright wrote:
> > On 4/26/2013 1:59 PM, Diggory wrote:
> >> The actual value shouldn't be taken into
> >> account when determining which overload to call, only the type
> >> should matter,
> >
> > D has an interesting feature called VRP (value range propagation), where implicit conversion very much depends on
>
> > the value. For example:
> Then perhaps ban VRP on arguments if it affects overloading?
No. The problem really isn't with VRP. The problem is the fact that D is weakly typed with regards to bool. In virtually all cases, having VRP do it's job is exactly what we want. It's just that in this one, weird things happen because of the implicit conversion to bool which is of zero utility in this case, because if that's what you wanted, you'd just use a boolean literal rather than an integer one.
I really think that allowing the implicit conversion to bool is truly helpful in only a small number of cases (e.g. arithmetic which wants to add 0 or 1 depending on the result of a boolean expression), and it clearly results in behavior that most people don't expect in quite a few instances. The fact that stuff like
auto b = false / true;
compiles is just downright bizarre.
- Jonathan M Davis
|
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, April 27, 2013 13:16:55 Walter Bright wrote: > In general, D treats bool, char, wchar, and dchar as integer types. D also follows the C practice of unadorned integer literals being typed as ints, and the C practice of default integral promotions. > > If you're not aware of this, yes, you can get surprised when working with overloads across those types. Yes, but I honestly think that that's problem too. I think that there's more of an argument for treating characters as integral types than bool, as they really do hold an encoded number internally, but they really aren't treated as integers in general, and I think that treating them as integers implicitly tends to cause problems when conversions come into play. True, it's nice to not have to cast '0' - 42 when assigning it back to a char, but I also don't think that it's all that big a deal for the cast to be required, and I think that allowing things like "foo" ~ 42 is just asking for bugs, particularly when you can easily do something like \u0042 if you actually want a numberic character literal. "foo" ~ true just so happens to be an extreme case of this, as it clearly makes no sense, and if it happens with variables rather than literals, it's not necessarily as obvious that it's happening. We need to be careful with how strongly stuff is typed, because we don't want to require casts everywhere, as that can introduce other types of bugs because casts are so blunt - which is why not requiring casting when converting between int and uint is probably ultimately a good idea - but characters and bool really aren't integral types, even if they do have a relation to them, and I firmly believe that treating them as integral types implicitly causes more bugs than it fixes. > The solution in the antecedent's particular case is to add an overload foo(int), which will neatly prevent any unadorned integer literals from being implicitly cast to char or bool or whatever. It's also a good practice in that unnecessarily promoting ints to longs is a bit of an efficiency issue. > > [Generally, I'd raise a red flag on any code that only provided foo(bool) > and foo(long) overloads.] Clearly, with how the language currently works, that should raise a red flag, but I think that it's clear that the majority of us would have expected foo(bool) to work with bools, and foo(long) to deal with integral values, allowing you to just have two overloads rather than several. > > However, we are clearly coming from very different points of view here. > > Thanks for understanding my point that this is not a right or wrong issue, but a matter of perspective. It is definitely a matter of perspective, but I also think that it's fairly clear that most people here don't expect bool to be treated as an integral type and don't like the fact that it is. If it's truly an integral type, why have true and false in the first place? Why not just use 1 and 0? It seems like implicit casting is making it so that there's no real difference between them, and C++ introduced a bool type rather than sticking with C's approach in order to be able to distinguish between bools and integers when overloading. We appear to be doing a poor job of that. - Jonathan M Davis |
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 04/28/2013 02:28 AM, Jonathan M Davis wrote:
> ... I like
> being able to do while(1) because it's shorter, ...
for(;;) is shorter.
|
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | On Saturday, April 27, 2013 07:54:44 =?UTF-8?B?Ikx1w61z?=.Marques <luismarques@gmail.com>@puremagic.com wrote: > Is this what some of you are asking for? > > bool a = true; // ok > bool b = false; // ok > bool c = 1; // error, no implicit conversion > bool c = getInt(); // error? ok? > int x = 42; > if(x) { ... } // ok (doesn't this imply c = > getInt() ok too? > if(42) { ... } // ok if conditions and loop conditions automatically insert explicit casts, so if(foo) becomes if(cast(bool)foo) which makes it so that you can define how a user-defined type will be treated when used in a condition and for built-in types completely removes if statements and loops from discussions on implicit conversion as there's no implicit conversion being used (unless you're arguing for the cast to not be inserted for conditions, in which case, implicit conversion _would_ be used). - Jonathan M Davis |
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Sunday, April 28, 2013 02:53:04 Timon Gehr wrote:
> On 04/28/2013 02:28 AM, Jonathan M Davis wrote:
> > ... I like
> > being able to do while(1) because it's shorter, ...
>
> for(;;) is shorter.
True, but I'd never use it, because I'd never use a for loop for anything that didn't involve either creating a variable in the first portion of the for or doing something in the last portion. I also find it very bizarre that it's legal to have a loop _without_ a condition like for(;;) does.
If you couldn't do while(1), I'd do while(true) and never for(;;), but that's obviously a matter of preference, and while I like being able to do while(1), I'd gladly give it up if that meant that we stopped treating bool as in integral type.
- Jonathan M Davis
|
April 28, 2013 Re: 1 matches bool, 2 matches long | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 27 April 2013 at 19:51:48 UTC, Walter Bright wrote: > On 4/26/2013 7:36 PM, Mehrdad wrote: >> Walter, you're completely missing the point. > > I completely understand it is a perception problem. Some people see bool as a 1 bit integer (including me). Some see bool as something very distinct from integers (including you). > Don't be silly. You don't see them as 1 bit integer, as they convert by comparing to 0 and not truncating. > What I find distressing about these kinds of threads is how people dig in and so fortify their position on a rather trivial matter and then it blows up into some do-or-die thing. It is not like this issue is popping for the first time. When a source of tension exists, any complaint about it can crystallize easily. |
Copyright © 1999-2021 by the D Language Foundation