What's the official word on this:  https://github.com/dlang/dmd/pull/6404

Does it need a DIP?

If I revive it will it go anywhere?

What needs to be done to move it forward?

Thanks,
Mike

On Saturday, November 11, 2017 13:40:23 Michael V. Franklin via Digitalmars- d wrote:
> What's the official word on this: https://github.com/dlang/dmd/pull/6404
>
> Does it need a DIP?
>
> If I revive it will it go anywhere?
>
> What needs to be done to move it forward?

It probably needs a DIP, since it's a language change, and based on what Walter has said in the past about this topic, I don't know how convincible he his. I think that most everyone else thought that it was terrible when code like this

auto foo(bool) {...}
auto foo(long) {...}

foo(1);

ends up with the bool overload being called, but Walter's answer was just to add an int overload if you didn't want 1 to call the bool overload. He may be more amenable to deprecating the implicit conversion now than he was then, but it's the sort of thing where I would expect there to have to be a DIP rather than it simply being done in a PR, since it's a definite semantic change and not one that Walter previously agreed should be made. I have no idea what Andrei's opinion on the topic is.

- Jonathan M Davis

Hi Mike, thanks for your inquiry. A DIP is necessary for all language changes. In this case a short and well-argued DIP seems to be the ticket. Walter and I spoke and such a proposal has a good chance to be successful.

Thanks,

Andrei

On 11/11/2017 08:40 AM, Michael V. Franklin wrote:
> What's the official word on this: https://github.com/dlang/dmd/pull/6404
> 
> Does it need a DIP?
> 
> If I revive it will it go anywhere?
> 
> What needs to be done to move it forward?
> 
> Thanks,
> Mike

On Saturday, 11 November 2017 at 14:54:42 UTC, Jonathan M Davis wrote:
> On Saturday, November 11, 2017 13:40:23 Michael V. Franklin via Digitalmars- d wrote:
>> What's the official word on this: https://github.com/dlang/dmd/pull/6404
>>
>> Does it need a DIP?
>>
>> If I revive it will it go anywhere?
>>
>> What needs to be done to move it forward?
>
> It probably needs a DIP, since it's a language change, and based on what Walter has said in the past about this topic, I don't know how convincible he his. I think that most everyone else thought that it was terrible when code like this
>
> auto foo(bool) {...}
> auto foo(long) {...}
>
> foo(1);
>
> ends up with the bool overload being called, but Walter's answer was just to add an int overload if you didn't want 1 to call the bool overload.

Yeah, this is bad.

However, I’d hate to rewrite things like:

if (a & (flag1 | flag2))

to

if ((a & (flag1 | flag2)) != 0)

When the first is quite obvious.

On Sunday, 12 November 2017 at 13:34:50 UTC, Dmitry Olshansky wrote:

> However, I’d hate to rewrite things like:
>
> if (a & (flag1 | flag2))
>
> to
>
> if ((a & (flag1 | flag2)) != 0)
>
> When the first is quite obvious.

I don't think the proposal to deprecate integer literal conversions to `bool` would affect that as there doesn't appear to be an integer literal in the code.

Mike

On Sunday, 12 November 2017 at 13:49:51 UTC, Michael V. Franklin wrote:

> I don't think the proposal to deprecate integer literal conversions to `bool` would affect that as there doesn't appear to be an integer literal in the code.

Nevermind. I see what you mean now.

Mike

On Sunday, 12 November 2017 at 13:34:50 UTC, Dmitry Olshansky wrote:
> if (a & (flag1 | flag2))
>
> to
>
> if ((a & (flag1 | flag2)) != 0)
>
> When the first is quite obvious.

Just change the typing of the if-conditional to:

if (boolean|integral) {…}

On Sunday, 12 November 2017 at 16:00:28 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 12 November 2017 at 13:34:50 UTC, Dmitry Olshansky wrote:
>> if (a & (flag1 | flag2))
>>
>> to
>>
>> if ((a & (flag1 | flag2)) != 0)
>>
>> When the first is quite obvious.
>
> Just change the typing of the if-conditional to:
>
> if (boolean|integral) {…}

There's no force change.
if explicitly converts cond to bool.

On 11/12/2017 08:54 AM, Michael V. Franklin wrote:
> On Sunday, 12 November 2017 at 13:49:51 UTC, Michael V. Franklin wrote:
> 
>> I don't think the proposal to deprecate integer literal conversions to `bool` would affect that as there doesn't appear to be an integer literal in the code.
> 
> Nevermind. I see what you mean now.
> 
> Mike

A DIP could be formulated to only address the problem at hand. BTW, here's a really fun example:

void fun(long) { assert(0); }
void fun(bool) {}

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

void main()
{
    fun(a - b);
}

The overload being called depends on (a) whether a - b can be computed during compilation or not, and (b) the actual value of a - b. Clearly a big problem for modular code. This is the smoking gun motivating the DIP.


Andrei

On Sunday, 12 November 2017 at 16:04:59 UTC, Temtaime wrote:
> There's no force change.
> if explicitly converts cond to bool.

Yes, but that is a flaw IMO. E.g. NaN will convert to true.