I filed the issue in bugzilla, and opened pull request to fix it.

http://d.puremagic.com/issues/show_bug.cgi?id=9999 https://github.com/D-Programming-Language/dmd/pull/1942

Kenji Hara


2013/4/28 kenji hara <k.hara.pg@gmail.com>

> OK. I misunderstood.
>
> C does not allow function overloading, so same problem is not there. In C++,
>
> // test.cpp
> #include <stdio.h>
> void foo(bool) { printf("bool\n"); }
> void foo(long) { printf("long\n"); }
> int main(int argc, char **argv)
> {
> foo(false);  // matches bool version
> foo(true);   // matches bool version
>  foo(0);  // ambiguous
> foo(1);  // ambiguous
>  foo(2);  // ambiguous
> return 0;
> }
>
> The behavior is same with GCC 4.7.2 (using msys) and dmc.
>
> Walter, now I changed my opinion. It seems not correct that being regarded
> bool type as one of the integer.
> How about?
>
> Kenji Hara
>
> 2013/4/27 Minas Mina <minas_mina1990@hotmail.co.uk>
>
>> On Saturday, 27 April 2013 at 11:41:30 UTC, kenji hara wrote:
>>
>>> First, I can guess that why Walter disagree *fixing* this problem.
>>>
>>> http://dlang.org/overview.html
>>>
>>>> Major Design Goals of D
>>>> 9. Where D code looks the same as C code, have it either behave the same
>>>>
>>> or issue an error.
>>>
>>>
>> C doesn't have a bool type, so how can D behave the same?
>>
>
>

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).

An analogous issue comes up here now and then about 'char' and characters. Are chars an 8 byte integer, or are they characters, or are they octets, or should access only be allowed to multibyte characters as an indivisible code point? (This comes up in regards to indexing char[].)


> The point is that people can live with the consequences of your short/long
> example, but they can't do the same with Andrej's bool/long example.
> No matter how right you are, if you keep insisting your way is correct, D will
> continue never becoming popular because people will continue finding it hard to
> use.

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.

On 4/26/2013 5:14 PM, H. S. Teoh wrote:
> Does VRP work only with literals, or does it work with general variables
> (by inferring from, say, if-conditions)?
>
> 	void func(int i) {
> 		ubyte b;
> 		if (i >= 0 && i < 256) {
> 			b = i;		// OK without cast?
> 		}
> 		...
> 	}

Such would require data flow analysis, which is beyond the scope of what the front end is designed to do. So, no, for the foreseeable future.

On 4/26/2013 9:19 PM, Maxim Fomin wrote:
> Then perhaps ban VRP on arguments if it affects overloading?

That'll just make another group of people unhappy.

It's like designing a house with a fixed footprint. You can make the kitchen larger and the bathroom smaller, or vice versa, but you can't make them both bigger.

On 4/27/2013 8:11 AM, kenji hara wrote:
> Walter, now I changed my opinion. It seems not correct that being regarded bool
> type as one of the integer.
> How about?

Both C and C++ regard bool as an integer, and implicitly convert 1/0 to true/false.

What C++ doesn't have is VRP and partial ordering of functions. (But it does have partial ordering of template functions.)

On 4/26/2013 3:28 PM, Jonathan M Davis wrote:
> Sure, it may be useful sometimes to have code that treats true as 1 and false
> as 0 for math, but I'd argue for casting being required for it, and in a large
> number of cases, casting would be required already due to the fact that it
> would be a narrowing conversion. But it seems very wrong to me that foo(1)
> would call a bool overload or that "foo" ~ true would compile.

It's not any different from how char is treated (char is also treated as an integer type).


> There have been
> a number of posts over time discussing bugs caused by that behavior being
> legal. I don't think that it's a huge problem, but I do think that it's a
> problem.

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.

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.]


> 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.

2013/4/28 Walter Bright <newshound2@digitalmars.com>

> On 4/27/2013 8:11 AM, kenji hara wrote:
>
>> Walter, now I changed my opinion. It seems not correct that being
>> regarded bool
>> type as one of the integer.
>> How about?
>>
>
> Both C and C++ regard bool as an integer, and implicitly convert 1/0 to true/false.
>
> What C++ doesn't have is VRP and partial ordering of functions. (But it does have partial ordering of template functions.)
>

I'm not argue that we should remove the implicit conversion from 1/0 to bool.

I don't have so much knowledge about C/C++ language spec, but for the issue
case C++ makes "ambiguous error".
Contrary of that, D's current behavior looks to me it is going back to past.

Kenji Hara

On 4/26/2013 11:04 PM, Steven Schveighoffer wrote:
> I think the issue (and I am firmly in the foo(1) => long camp) is that bools are
> considered better integers than actual integer types (or even floating point
> types for that matter).  I agree that bools can be implicitly cast to and from
> integers, as a last resort.

The overload system in D is explicitly not based on "better". (The C++ "better" overloading system is for functions, but not for templates.) The D overload system is based on partial ordering, which is the same as what C++ uses for templates.

I don't know for a fact, but I'm pretty sure the partial ordering scheme that C++ selected for templates, which came along many years later, was picked because people realized it was better (and more mathematically robust and defensible).

One of the problems with a "better" matching system is handling functions with multiple parameters, each with their own "better" match. (The C++ Standard devotes a great deal of complex text to this, it boils down to a bunch of rather arbitrary decisions.) Partial ordering solves this neatly and consistently.

As one who implemented C++'s better matching system, I can confidently state that the partial ordering scheme is FAR better overall.

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).


The problem is 'bool' has *NOTHING* in common with integers!

- Can't use + - * / << >> on bool's
- (bool)2 == (bool)1  (do you SERIOUSLY think this is integer-like?)
- sizeof(int64) == 8 * sizeof(int8)
- sizeof(int8 ) != 8 * sizeof(bool)


There is literally _NOTHING_ about bool that's integer-like, and for some reason you still think bool is an integer.

And you still wonder why people find D frustrating?


> An analogous issue comes up here now and then about 'char' and characters.

That was a C++ mistake, I hope you're not trying to repeat it.

Heck, even in C++, you can make sense out of it if you stick with the convention:

- "char" == character
- "unsigned char" == ubyte
- "signed char" == sbyte

(This is a quotation from http://d.puremagic.com/issues/show_bug.cgi?id=9999<http://d.puremagic.com/issues/show_bug.cgi?id=9999#c4> )

> I do not agree with this enhancement. First off, making special cases for partial ordering takes a simple, straightforward idea and turns it into a potential morass of conflicting cases that we'll be stuck with forever. Secondly, the only issue here is whether '1' should be implicitly
convertible
> to 'bool'.

Walter, I can understand your concern. But I think it would not be so big. Because the possibility of extending basic type set is not so much in the future.

Keeping language spec simple is necessary, but also reduce special rule for
humans is also important. This is a much rare case that is the mismatch
between
simple rule and natural behavior for human. Fixing this issue would be
valuable
for many D users.

Logically 'true' and  'false' are not related to any integer values.
Although
it is widely known and used, considering boolean type as a kind of
specialized
integer type is not general - it is implementation detail. At least it comes
from C language. In old ages, boolean type had not been supported properly
in
many programming languages, but today, languages which not supporting it
would
not regarded as useful. D is a modern programming language, so more proper
behavior for boolean type is necessary.

As one of its goal, D should aim the successor of C. Therefore, we cannot
drop
the implicit conversion between bool and other integer types which inherited
from C.
But this problem behavior is definitely unnatural for many programmers, and
would enforce to study bad know-how for them. Loosing future users for the
compiler simplicity is not good decision. Of course, balance is necessary
there, but I think this is necessary complexity.

Kenji Hara


2013/4/28 kenji hara <k.hara.pg@gmail.com>

> 2013/4/28 Walter Bright <newshound2@digitalmars.com>
>
>> On 4/27/2013 8:11 AM, kenji hara wrote:
>>
>>> Walter, now I changed my opinion. It seems not correct that being
>>> regarded bool
>>> type as one of the integer.
>>> How about?
>>>
>>
>> Both C and C++ regard bool as an integer, and implicitly convert 1/0 to true/false.
>>
>> What C++ doesn't have is VRP and partial ordering of functions. (But it does have partial ordering of template functions.)
>>
>
> I'm not argue that we should remove the implicit conversion from 1/0 to bool.
>
> I don't have so much knowledge about C/C++ language spec, but for the
> issue case C++ makes "ambiguous error".
> Contrary of that, D's current behavior looks to me it is going back to
> past.
>
> Kenji Hara
>