bool promotion rules

[quickfur]

Another idea rejected by Walter: treat bool as a separate type from int and disable implicit promotion to int. Does this make sense, or are the current int promotion rules better?

[andrey-zherikov]

I think there should be two questions:

1. Should true and false be implicitly converted to 1 and 0 respectively?
2. Should 0 and non-zero integer values be implicitly converted to true and false respectively?

[ssvb]

Ideally, all unexpected arithmetic overflows should be caught at runtime at least in debug builds. The a = -a expression has a tricky corner case:

byte a = -128;
a = -a;

If the overflow is actually desired, then this can be written as

byte a = -128;
a = negs(a);

Modern programming languages (such as Rust, Crystal or Swift) allow catching arithmetic overflows. Even C++ can do it for signed overflows with UBSan.

[ssvb]

Implicit conversion should only be from signed or unsigned types to larger signed types. Never from signed to unsigned.

+1

The comparison of two values shall always give the correct result, no matter what size the types are and no matter the signedness. This takes one additional 'if' in the case that signed is compared to unsigned, but if this is a performance problem: fix your code!

+1 (this is implemented in Crystal language and works fine)

Though this may silently break compatibility with some oddly written code. So not sure what's the best way to smoothly transition to this.

[adamdruppe]

i think the ubsan thing might work with ldc too

[ntrel]

people using 16bit or even 8bit types should be well aware of overflows and how to handle them

All I meant was that integer promotion is useful to avoid overflow:

byte a, b;
auto c = a * b;

People coming from C, C++ are going to expect promotion.

[Lyratelle]

Sorry, but I would expect c to be of type byte. Also C doesn't have auto, so why should there be some special expectation?
(And even if C had auto, you should avoid it in such places. Simply state what type you would like c to be).
Yes, the calculation of a*b can be done in the machine word size, but the result should be automatically truncated (or extended) to the type of c. And if you want the type to be inferred, if should be the same type as the operands.

[quickfur]

The promotion-rules are awful

Another problem is integer types implicitly converting to character types. (The other direction is maybe OK).
[...]

Yeah, the entire raison d'etre of char, wchar, and dchar is to differentiate them from integral types. Having them implicitly convert to each other, or worse yet, having a char match an int function overload or an int match a char function overload is just pure bonkers. IMO all char types should not be interconvertible with int types. If you want to be doing arithmetic with ASCII values or Unicode codepoint values (usually a bad idea but sometimes necessary), you should be forced to use ugly cast()s to express your actual intentions. Having it all happen implicitly is just a bad idea. It makes code confusing to write and even more confusing to read and debug afterwards.

Kill it with fire and extreme prejudice, I say.

[crazymonkyyy]

I like true+true=2 and true*a=a

[Lyratelle]

I don't.

[ntrel]

Multiplying by bool is nice to avoid a cast, e.g. in branchless programming. I don't see why we need implicit bool -> int addition though.

[crazymonkyyy]

I think of two main cases

i+=isGrowing

switch(s.isntempty + s.specailcase){
  case 0://empty
  case 1://normal
  case 2://special case

[ssvb]

you should be forced to use ugly cast()s to express your actual intentions. Having it all happen implicitly is just a bad idea. It makes code confusing to write and even more confusing to read and debug afterwards.

A safer idiomatic variant with runtime safety checks for arithmetic overflows is:

  int x = 1234;
  char y = x.to!char; // and it's shorter than "cast(char)x"

In the obvious cases the compiler is able to optimize it out, similar to how it can optimize out some of the array bounds checking. Possibly even an extra compiler option can be introduced to omit overflow checks in such expressions to satisfy the needs of those, who want to trade safety for a little bit of extra performance (effectively complementing the existing -boundscheck=off option).

[Lyratelle]

If I use cast, I expect a simple truncation (as fast as possible, no care taken about overflow or lost fraction part or whatever). And also if I implement some opCast I use this principle. If you want something that takes more care about arithmetic checks, use a constructor T(x) instead of some generic function x.to!T. The later is a last resort if no fitting constructor is available (and most likely in this case you have to write your own overload of to()).

[IgorDeepakM]

I'd say just change it.
No implicit bool conversions from/to numerics.
No implicit integer lossy conversions.
No implicit conversions between char types and integer (which should also have the opportunity to be checked).
Totally ban boolean operators for the built in integers that are not of the same type or can loss less implicitly converted.

There can even be a justification to force explicit conversion from non lossy conversion. Rust has this and must use as or ::from.

let i: u8 = 1;
let u: i32::from(i);

I'm a bit unsure if this is taking it too far.

We have the chance now to get rid of this and it will help us to avoid bugs. People who like to do arithmetics with bool/chars will lose nothing, just an additional cast to show the intention.