www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1015--removal of implicit conversion from integer and character

reply Mike Parker <aldacron gmail.com> writes:
This is the feedback thread for the first round of Community 
Review for DIP 1015, "Deprecation and removal of implicit 
conversion from integer and character literals to bool":

https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on July 4, or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the 
DIP will be scheduled for another round. Otherwise, it will be 
queued for the Final Review and Formal Assessment by the language 
maintainers.

Please familiarize yourself with the documentation for the 
Community Review before participating.

https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

Thanks in advance to all who participate.
Jun 20 2018
next sibling parent reply Chris M. <chrismohrfeld comcast.net> writes:
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review for DIP 1015, "Deprecation and removal of implicit 
 conversion from integer and character literals to bool":

 [...]


Yes please
Jun 20 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jun 20, 2018 at 01:30:56PM +0000, Chris M. via Digitalmars-d wrote:

 On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community Review
 for DIP 1015, "Deprecation and removal of implicit conversion from
 integer and character literals to bool":
 
 [...]


 
 Yes please


Seconded.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well
onto the problem space, which is also a mess, which we call reality. Similarly,
Perl was designed to be a mess, though in the nicest of all possible ways. --
Larry Wall
Jun 20 2018
parent Anton Fediushin <fediushin.anton yandex.com> writes:
On Wednesday, 20 June 2018 at 16:10:26 UTC, H. S. Teoh wrote:

 On Wed, Jun 20, 2018 at 01:30:56PM +0000, Chris M. via 
 Digitalmars-d wrote:

 On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review for DIP 1015, "Deprecation and removal of implicit 
 conversion from integer and character literals to bool":
 
 [...]


 
 Yes please


 Seconded.


 T


Count me in. Even though I never write code like bool foo = '\0'; 
I can see why this DIP is helpful and what kind of errors it can 
prevent.
Jun 20 2018
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review for DIP 1015, "Deprecation and removal of implicit 
 conversion from integer and character literals to bool":

 [...]


This is similar to the overload bug that c++ has with the marco 
NULL before it was fixed in c++11.
Jun 20 2018
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review for DIP 1015, "Deprecation and removal of implicit 
 conversion from integer and character literals to bool":

 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md

 All review-related feedback on and discussion of the DIP should 
 occur in this thread. The review period will end at 11:59 PM ET 
 on July 4, or when I make a post declaring it complete.

 At the end of Round 1, if further review is deemed necessary, 
 the DIP will be scheduled for another round. Otherwise, it will 
 be queued for the Final Review and Formal Assessment by the 
 language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.


Example D

```
Enum int a = 2;
Enum int b = 1;
```
should be `enum`.

Otherwise, YES!!!!
Jun 20 2018
prev sibling next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review for DIP 1015, "Deprecation and removal of implicit 
 conversion from integer and character literals to bool":

 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md

 All review-related feedback on and discussion of the DIP should 
 occur in this thread. The review period will end at 11:59 PM ET 
 on July 4, or when I make a post declaring it complete.

 At the end of Round 1, if further review is deemed necessary, 
 the DIP will be scheduled for another round. Otherwise, it will 
 be queued for the Final Review and Formal Assessment by the 
 language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review


Just a little remark in the Rationale section. C does have a bool 
alias of _Bool type and false and true keywords since C99. So it 
is wrong to say C doesn't have them. Doesn't change anything on 
the rest of the paper but is it better to not propagate 
falsehoods.
Jun 21 2018
prev sibling next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review for DIP 1015, "Deprecation and removal of implicit 
 conversion from integer and character literals to bool":

 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md


The arguments are clear and convincing, so: Yes!
Jun 21 2018
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/20/18 4:16 AM, Mike Parker wrote:

 This is the feedback thread for the first round of Community Review for 
 DIP 1015, "Deprecation and removal of implicit conversion from integer 
 and character literals to bool":
 
 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb57
d84/DIPs/DIP1015.md 
 
 
 All review-related feedback on and discussion of the DIP should occur in 
 this thread. The review period will end at 11:59 PM ET on July 4, or 
 when I make a post declaring it complete.
 
 At the end of Round 1, if further review is deemed necessary, the DIP 
 will be scheduled for another round. Otherwise, it will be queued for 
 the Final Review and Formal Assessment by the language maintainers.
 
 Please familiarize yourself with the documentation for the Community 
 Review before participating.
 
 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
 
 Thanks in advance to all who participate.
 
 


I agree with everything, but one thing that is not specified here is 
when integers are used as conditionals.

In other words, this still has to compile:

if(1) ...

enum a = 1;

if(a) ...

I can see this somehow getting caught up in the "implicit conversion to 
bool", so there should be a section to address this.

-Steve
Jun 21 2018
next sibling parent reply Francesco Mecca <me francescomecca.eu> writes:
On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer 
wrote:

 On 6/20/18 4:16 AM, Mike Parker wrote:

 [...]


 I agree with everything, but one thing that is not specified 
 here is when integers are used as conditionals.

 In other words, this still has to compile:

 if(1) ...

 enum a = 1;

 if(a) ...

 I can see this somehow getting caught up in the "implicit 
 conversion to bool", so there should be a section to address 
 this.

 -Steve


I agree and after reading the DIP I am still confused if we are 
allowed to write while(1) (and similar conditionals) anymore.
Jun 21 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, June 21, 2018 18:56:39 Francesco Mecca via Digitalmars-d wrote:

 On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer

 wrote:

 On 6/20/18 4:16 AM, Mike Parker wrote:

 [...]


 I agree with everything, but one thing that is not specified
 here is when integers are used as conditionals.

 In other words, this still has to compile:

 if(1) ...

 enum a = 1;

 if(a) ...

 I can see this somehow getting caught up in the "implicit
 conversion to bool", so there should be a section to address
 this.

 -Steve


 I agree and after reading the DIP I am still confused if we are
 allowed to write while(1) (and similar conditionals) anymore.


while(1)

is not technically an implicit conversion. It's an implicit, explicit
conversion, which sounds kind of dumb, but it is technically what happens,
since when you write a conditional, the compiler inserts an explicit cast.
So, when you write something like

if(foo)

it becomes

if(cast(bool)foo)

So, while you don't explicitly put the cast there, semantically, that's
what's happening, whereas actual implicit conversions don't use casts.
That's why you can do typically stuff like

if(myObject)

but can't do

bool b = myObject;

Any type that can be explicitly cast to bool can therefore be used in a
conditional, but only a type with an implicit conversion can be assigned to
a bool, passed to a function that accepts bool, or be used in any other
situation where an actual bool is required.

So, since the DIP just talks about altering implicit conversions, I think
that that it's actually pretty clear that it does not affect conditionals.
That being said, it wouldn't be a bad idea to explicitly state in there that
it has no effect on code like conditionals where explicit casts are inserted
by the compiler.

- Jonathan M Davis
Jun 21 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/21/18 3:29 PM, Jonathan M Davis wrote:

 On Thursday, June 21, 2018 18:56:39 Francesco Mecca via Digitalmars-d wrote:

 On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer

 wrote:

 On 6/20/18 4:16 AM, Mike Parker wrote:

 [...]


 I agree with everything, but one thing that is not specified
 here is when integers are used as conditionals.

 In other words, this still has to compile:

 if(1) ...

 enum a = 1;

 if(a) ...

 I can see this somehow getting caught up in the "implicit
 conversion to bool", so there should be a section to address
 this.


 I agree and after reading the DIP I am still confused if we are
 allowed to write while(1) (and similar conditionals) anymore.


 
 while(1)
 
 is not technically an implicit conversion. It's an implicit, explicit
 conversion, which sounds kind of dumb, but it is technically what happens,
 since when you write a conditional, the compiler inserts an explicit cast.


I'm not so sure this is the case for integer literals (literally, I'm 
not sure). It's certainly the case for custom types. The compiler 
handles things with builtin types specially. See for instance foreach on 
ranges vs. arrays.

It might be that this actually is an implicit conversion (it's a literal 
after all). In that case, what I DON'T want to see after this proposal 
is accepted is an explanation like "well, why wouldn't you just use 
while(true)? It's the same thing".

It's why I think the document needs clarification.

-Steve
Jun 21 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, June 21, 2018 17:23:12 Steven Schveighoffer via Digitalmars-d 
wrote:

 On 6/21/18 3:29 PM, Jonathan M Davis wrote:

 On Thursday, June 21, 2018 18:56:39 Francesco Mecca via Digitalmars-d 




wrote:

 On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer

 wrote:

 On 6/20/18 4:16 AM, Mike Parker wrote:

 [...]


 I agree with everything, but one thing that is not specified
 here is when integers are used as conditionals.

 In other words, this still has to compile:

 if(1) ...

 enum a = 1;

 if(a) ...

 I can see this somehow getting caught up in the "implicit
 conversion to bool", so there should be a section to address
 this.


 I agree and after reading the DIP I am still confused if we are
 allowed to write while(1) (and similar conditionals) anymore.


 while(1)

 is not technically an implicit conversion. It's an implicit, explicit
 conversion, which sounds kind of dumb, but it is technically what
 happens, since when you write a conditional, the compiler inserts an
 explicit cast.


 I'm not so sure this is the case for integer literals (literally, I'm
 not sure). It's certainly the case for custom types. The compiler
 handles things with builtin types specially. See for instance foreach on
 ranges vs. arrays.

 It might be that this actually is an implicit conversion (it's a literal
 after all). In that case, what I DON'T want to see after this proposal
 is accepted is an explanation like "well, why wouldn't you just use
 while(true)? It's the same thing".

 It's why I think the document needs clarification.


In the general case, it has to be an explicit conversion even with literals,
because stuff like

while(2)

works. So, I think that it's quite clear that simply getting rid of the
implicit conversion of 1 to true can't affect conditionals (though it's
certainly possible that the current implementation would run into issues
depending on whether the compiler always literally inserts an explicit cast
or whether it just does so when it would be required). It simply doesn't
make sense that while(1) would fail to work when while(2) continued to work
just fine. The semantics of conditionals require that while(1) would
continue to work even if the implicit conversion to bool is removed. As
such, I think that it's pretty clear what the DIP has to mean if you
understand the semantics of conditionals.

But that being said, I agree that the DIP should be clarified. Plenty of
folks don't understand conditionals properly and would mistakingly come to
the conclusion that this was banning while(1), and there's no reason not to
just be explicit about it for the sake of clarity. We don't want folks to be
confused about it, and it should be fairly easy to make the DIP clear on the
matter.

- Jonathan M Davis
Jun 21 2018
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer 
wrote:


 I agree with everything, but one thing that is not specified 
 here is when integers are used as conditionals.

 In other words, this still has to compile:

 if(1) ...

 enum a = 1;

 if(a) ...


Although I would prefer it if such code was not allowed without a 
cast, it is out of scope of this DIP.

I've added a test to the implementation at 
https://github.com/dlang/dmd/pull/7310/files#diff-d14bf83f2992
ca109a2e5315174791a to ensure it doesn't break, and updated the DIP to clarify
at https://github.com/dlang/DIPs/pull/127/files.

Thanks for the feedback.

Mike
Jun 21 2018
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/22/18 12:33 AM, Mike Franklin wrote:

 On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer wrote:
 

 I agree with everything, but one thing that is not specified here is 
 when integers are used as conditionals.

 In other words, this still has to compile:

 if(1) ...

 enum a = 1;

 if(a) ...


 
 Although I would prefer it if such code was not allowed without a cast, 
 it is out of scope of this DIP.
 
 I've added a test to the implementation at 
 https://github.com/dlang/dmd/pull/7310/files#diff-d14bf83f2992
ca109a2e5315174791a 
 to ensure it doesn't break, and updated the DIP to clarify at 
 https://github.com/dlang/DIPs/pull/127/files.
 
 Thanks for the feedback.


Thanks, that looks good. Full support from me!

-Steve
Jun 22 2018
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review for DIP 1015, "Deprecation and removal of implicit 
 conversion from integer and character literals to bool":

 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md

 All review-related feedback on and discussion of the DIP should 
 occur in this thread. The review period will end at 11:59 PM ET 
 on July 4, or when I make a post declaring it complete.

 At the end of Round 1, if further review is deemed necessary, 
 the DIP will be scheduled for another round. Otherwise, it will 
 be queued for the Final Review and Formal Assessment by the 
 language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.


The case of `assert(0, "this should not happen");` is not 
covered. Is this it allowed ?
Jun 21 2018
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 21 June 2018 at 17:48:11 UTC, Basile B. wrote:


 The case of `assert(0, "this should not happen");` is not 
 covered. Is this it allowed ?


That will not be affected by this DIP. I've updated the DIP to 
clarify at
https://github.com/dlang/DIPs/pull/127/files

Thanks for the feedback.

Mike
Jun 21 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, June 20, 2018 08:16:21 Mike Parker via Digitalmars-d wrote:

 This is the feedback thread for the first round of Community
 Review for DIP 1015, "Deprecation and removal of implicit
 conversion from integer and character literals to bool":

 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d8
 4/DIPs/DIP1015.md

 All review-related feedback on and discussion of the DIP should
 occur in this thread. The review period will end at 11:59 PM ET
 on July 4, or when I make a post declaring it complete.

 At the end of Round 1, if further review is deemed necessary, the
 DIP will be scheduled for another round. Otherwise, it will be
 queued for the Final Review and Formal Assessment by the language
 maintainers.

 Please familiarize yourself with the documentation for the
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.


I think that this is a fantastic idea and that experience has shown that on
the whole, the implicit conversion to bool causes far more bugs than it
fixes and that the annoyance that the extra explicit casts would cause do
not outweigh how error-prone it is for most programmers. So, I'm very much
behind this.

The only improvement I can think of is what Steven pointed out about
conditionals. Technically, conditionals are implicit, explicit casts (in
that the compiler inserts an explicit cast for the programmer). So,
something like

while(1)

is lowered to

while(cast(bool)1)

and does not actually rely on implicit conversions. That's why something
like

if(auto value = key in aa)

works, whereas

bool present = key in aa;

doesn't. However, that's not clear to everyone, and so the DIP should be
clear that it does not affect conditionals, since in those cases, the
compiler inserts an explicit casts. The DIP just puts integer and character
literals in the same boat as something like string literals in that

if("foo")

compiles just fine, whereas

bool b = "foo";

does not.

- Jonathan M Davis
Jun 21 2018
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2018-06-20 10:16, Mike Parker wrote:

 This is the feedback thread for the first round of Community Review for
 DIP 1015, "Deprecation and removal of implicit conversion from integer
 and character literals to bool":


The text says: "Only literals that evaluate to 0 or 1 are affected; all 
other literals are to remain unchanged" [1]. This goes against example A 
[2].

[1] 
https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#description

[2] 
https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#example-a

-- 
/Jacob Carlborg
Jun 22 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/22/18 11:31 AM, Jacob Carlborg wrote:

 On 2018-06-20 10:16, Mike Parker wrote:

 This is the feedback thread for the first round of Community Review for
 DIP 1015, "Deprecation and removal of implicit conversion from integer
 and character literals to bool":


 
 The text says: "Only literals that evaluate to 0 or 1 are affected; all 
 other literals are to remain unchanged" [1]. This goes against example A 
 [2].
 
 [1] 
 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DI
1015.md#description 
 
 
 [2] 
 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/
IP1015.md#example-a 
 
 


Which literals don't evaluate to 0 or 1 in example A?

Also, example A is just showing what currently compiles, not what is to 
be affected.

-Steve
Jun 22 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-06-22 17:46, Steven Schveighoffer wrote:

 On 6/22/18 11:31 AM, Jacob Carlborg wrote:

 On 2018-06-20 10:16, Mike Parker wrote:

 This is the feedback thread for the first round of Community Review for
 DIP 1015, "Deprecation and removal of implicit conversion from integer
 and character literals to bool":


 The text says: "Only literals that evaluate to 0 or 1 are affected;
 all other literals are to remain unchanged" [1]. This goes against
 example A [2].

 [1]
 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#description


 [2]
 https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#example-a


 Which literals don't evaluate to 0 or 1 in example A?


I read that as only the 0 and 1 literals would be affected by this 
proposal, i.e. the integer literals. But the examples are mentioning 
character literals as well. But if the character literals are evaluated 
to 0 or 1, perhaps everything is covered. But at least to me it's a bit 
unclear.


 Also, example A is just showing what currently compiles, not what is to
 be affected.


Then Example D is a better example [1].

[1] 
https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#example-d

-- 
/Jacob Carlborg
Jun 23 2018
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 23 June 2018 at 08:03:40 UTC, Jacob Carlborg wrote:


 I read that as only the 0 and 1 literals would be affected by 
 this proposal, i.e. the integer literals. But the examples are 
 mentioning character literals as well. But if the character 
 literals are evaluated to 0 or 1, perhaps everything is 
 covered. But at least to me it's a bit unclear.


The DIP attempts to disambiguate that by using conventions.  When 
referring to code it always uses backticks.  When referring to 
English interpretation of the words, it does not.

The DIP states "integer and character literals that evaluate to 0 
and 1".  Note that it doesn't say "`int` literals" and "`char` 
literals", nor does it say "`0`" or "`1`".  Therefore, the DIP is 
using the English interpretation of the words "integer", 
"character", "0", and "1".  "integer" means `int`, `uint`, 
`long`, etc, "character" means `char`, `dchar`, `wchar`, etc, "0" 
means `0`, `0L`, `'\0'`, etc. and "1" means `1`, `1L`, `'\1'`, 
etc.

I hope that helps.

Mike
Jun 23 2018
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 23 June 2018 at 10:18:04 UTC, Mike Franklin wrote:


 The DIP states "integer and character literals that evaluate to 
 0 and 1".


But I see that in the "Description" it uses `0` and `1`, so I'll 
remedy that with my next round of edits.

Thanks for the feedback.

Mike
Jun 23 2018