bool <=> int. WTF. (DIP0015)

[a11e99z]

On Wednesday, 3 July 2019 at 07:47:26 UTC, Zoadian wrote:
> On Tuesday, 2 July 2019 at 17:43:27 UTC, Les De Ridder wrote:
>> On Tuesday, 2 July 2019 at 17:04:24 UTC, Jonathan M Davis 
>> wrote:
>>> [...]
>> Can we fix the implementation and the spec, then?
>
> +1
>
> Either make bool a real boolean type and disallow implicit 
> conversions, or make it a true 1-bit integer type that actually 
> behaves like all the other int types.
> It's confusing as heck right now.

I vote for real boolean
and disallow only implicit conversions to bool for enums:NotBool
and consider option conversions to bool for 
byte/int/char/long/real/any arithmetics at last when no other 
options.

selection for fn(8-7) that prefers fn(bool) instead fn(long) 
looks weird and incomprehensible and looks more weird when 
fn(9-7) prefers fn(long) - for one type arg selects two different 
funcs.
well, we used int literals expliciltly here. what to do when some 
unpredictable const folding will give to us 0,1,2? sit and debug. 
why and for what?

if adds to sample
fn( byte a ) { ... }
than for enums and const 2 (or const foldings that gives 2) 
invokes byte version. why again? why compiler fucks the Integer 
Promotions https://dlang.org/spec/type.html#integer-promotions 
and next Usual Arithmetic Conversions? why choose byte or bool 
version for 8 that is int32? why choose byte or bool version for 
8-7 that is int32? why try to look for int32 arithmetics less 
size options? why adding fn( int1/8/16 ) changes logic of program 
so much?

pleeease make adequate decision (my version of such decision):
- enums with NoBool base type don't convert to bool implicitly at 
all.
enums with intXX base type supports implicit conversion to intXX 
but don't consider after it 2nd implicit conversion to bool
   if (DayOfWeek.tue) ... // WTF?
(by the way Tuesday is 3rd day of week(0,1,2=3rd) for 
USA/Canada/Japan and 2nd(0,1=2nd) for others)
- don't consider implicitly less size version.
- for one type make call only same one version of function that 
follow IP rules for ever. // fn(8-7) and fn(9-7) calls only 
fn(long) for sample
- consider bool option last.
- (can be discussed) any arithmetics for fundamental ints (not 
for user types with user ops) lesser that 32-bit gives int32. for 
ever.
   100i8 + 100i16 = 200i32
- add suffixes to integer literals u8/u16/u32/u64/u128 and 
i8/../i128 (last for cent & ucent) that can allow select func for 
literals without explicit cast
fn( cast( byte )100 ); // calls fn( byte )
fn( 100i8 ); // same

totally, for int32 try to use long/ulong/double/real version than 
try to use bool version and don't try to use less size versions 
implicitly. implicit conversion for int32 to int1/int8/uint16 are 
prohibited.