On Wed, May 18, 2022 at 10:11:34PM +0000, max haughton via Digitalmars-d wrote:
> For example:
> 
> float x = 'a';
> 
> Currently compiles. I had no idea that it does but I was implementing this pattern in SDC and lo and behold it does (and thus sdc has to support it).
> 
> Should it? Implicit conversions and implicit-anything around floats seem to be very undocumented in the specification too.

If you were to ask me, I'd say prohibit implicit conversions between char and non-char types. Otherwise you end up with nonsense code like the above.

But IIRC, the last time this conversation came up, Walter's view was that they are all integral types and therefore should be interconvertible.  The topic at the time was bool vs int, but the same principle holds in this case.


T

-- 
MSDOS = MicroSoft's Denial Of Service

On 5/18/2022 3:31 PM, H. S. Teoh wrote:
> If you were to ask me, I'd say prohibit implicit conversions between
> char and non-char types. Otherwise you end up with nonsense code like
> the above.
> 
> But IIRC, the last time this conversation came up, Walter's view was
> that they are all integral types and therefore should be
> interconvertible.  The topic at the time was bool vs int, but the same
> principle holds in this case.

People routinely manipulate chars as integer types, for example, in converting case. Making them not integer types means lots of casting will become necessary, and overall that's a step backwards.

On Thursday, 19 May 2022 at 00:27:24 UTC, Walter Bright wrote:
> On 5/18/2022 3:31 PM, H. S. Teoh wrote:
>> If you were to ask me, I'd say prohibit implicit conversions between
>> char and non-char types. Otherwise you end up with nonsense code like
>> the above.
>> 
>> But IIRC, the last time this conversation came up, Walter's view was
>> that they are all integral types and therefore should be
>> interconvertible.  The topic at the time was bool vs int, but the same
>> principle holds in this case.
>
> People routinely manipulate chars as integer types, for example, in converting case. Making them not integer types means lots of casting will become necessary, and overall that's a step backwards.

People do indeed (I'd question whether it's routine in a good D program, I'd flag it in code review) manipulate characters as integers, but I think there's something to be said for forcing people to go char -> suitable integer -> char.

We have u/byte, largely for descriptive purposes already, personally I try to use them for calculation even if the byte's value is from a char.

On Wed, May 18, 2022 at 05:27:24PM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/18/2022 3:31 PM, H. S. Teoh wrote:
> > If you were to ask me, I'd say prohibit implicit conversions between char and non-char types. Otherwise you end up with nonsense code like the above.
> > 
> > But IIRC, the last time this conversation came up, Walter's view was that they are all integral types and therefore should be interconvertible.  The topic at the time was bool vs int, but the same principle holds in this case.
> 
> People routinely manipulate chars as integer types, for example, in converting case. Making them not integer types means lots of casting will become necessary, and overall that's a step backwards.

How is that any different from the current situation where arithmetic involving short ints require casts all over the place?  Even things like this require a cast:

	short s = 123;
	//s = -s; // NG
	s = cast(short)-s; // required excess verbiage

It got so out of hand that I wrote nopromote.d, specifically to "poison" expressions involving short ints with a custom struct with overloaded ops that always truncate, just so I don't have to litter my code with casts in just about every expression involving short ints.


In the case of char + int arithmetic, my opinion is that usually people do *not* (or *should* not) do char arithmetic directly -- with Unicode, it makes much less sense than the bad ole days of ASCII. These days, you'd call one of the std.uni functions for proper case mapping instead of a slipshod hack job of adding or subtracting some magic constant (which is wrong in anything except ASCII anyway).  In today's day and age, strings are best treated as opaque data that are manipulated by properly-implemented string functions in the standard library.  Having a few extra char/int casts in std.uni isn't the end of the world.  It shouldn't usually be done in user code anyway.  (And having to write lots of casts may motivate people to actually use proper string manipulation functions instead of winging it themselves with wrong implementations involving char arithmetic.)


T

-- 
Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be algorithms.

On 5/18/2022 5:55 PM, max haughton wrote:
> People do indeed (I'd question whether it's routine in a good D program, I'd flag it in code review) manipulate characters as integers, but I think there's something to be said for forcing people to go char -> suitable integer -> char.

Casts are a common source of bugs, not correctness. This is because it is forced override of the type system. If the types change due to refactoring, the cast may no longer be correct, but the programmer will have no way of knowing.