https://issues.dlang.org/show_bug.cgi?id=14035

Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #9 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to yebblies from comment #6)
> Then, because it knows that 4 can fit in a char, it allows it to become this:
> 
> enum alice = "{ int t_"~cast(char)4~" = 42; }";

I think the problem is here. The constfold will change the value type uint to char unintentionally. I think the bare integer literal `4` and the expanded value `4` from a manifest constant `ln` should be handled differently.

- A bare integer literal `4` should work as a polysemous expression, so implicit casting it to char is possible because 4 can fit the value range of char type.

- An expanded integer `4` typed uint should work as an "interger", at least.
Therefore converting it to char implicitly is unnatural behavior.
(With the same logic, `ln` should not be implicitly convertible to bool.)

=====

To support human natural consequence, I think D built-in type should be
categorized as follows:
- numeric types: u?byte, u?short, u?int, u?long, [ic]?float, [ic]?double,
[ic]?real
- character types: [wd]?char
- boolean type: bool

and disallow conversions beyond the categories for non-polymorphic literals
(eg. `4` type with uint).

--

https://issues.dlang.org/show_bug.cgi?id=14035

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ketmar@ketmar.no-ip.org     |

--

https://issues.dlang.org/show_bug.cgi?id=14035

--- Comment #10 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
i did. yet i still can't see how this helps with three different `size_t` in D. but i clearly see why D will never be popular, with it's roots in old-fashioned "you have to know compiler internals to predict what compiler will do with your code". this makes me sad ketmar. ignoring human psychology is not the best way to make language popular, and i'm not talking about myself here. human tends to avoid unpredictable things if they have choice, and D has no killer app or software giant to support it, so the only way to win a fight is to be consistent and predictable. yet somethow the only consistent thing is consostent ignoring that facts. sad ketmar is sad.

--

https://issues.dlang.org/show_bug.cgi?id=14035

--- Comment #11 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to Kenji Hara from comment #9)
> and disallow conversions beyond the categories for non-polymorphic literals
> (eg. `4` type with uint).

Of course, even inside same category, loss of precision should also be disallowed.

eg. A implicit conversion from a floating literal `3.14` typed real to int will loss the precision, so it should be disallowed.

--

https://issues.dlang.org/show_bug.cgi?id=14035

--- Comment #12 from yebblies <yebblies@gmail.com> ---
(In reply to Kenji Hara from comment #9)
> (In reply to yebblies from comment #6)
> > Then, because it knows that 4 can fit in a char, it allows it to become this:
> > 
> > enum alice = "{ int t_"~cast(char)4~" = 42; }";
> 
> I think the problem is here. The constfold will change the value type uint to char unintentionally. I think the bare integer literal `4` and the expanded value `4` from a manifest constant `ln` should be handled differently.
> 
> - A bare integer literal `4` should work as a polysemous expression, so implicit casting it to char is possible because 4 can fit the value range of char type.
> 
> - An expanded integer `4` typed uint should work as an "interger", at least.
> Therefore converting it to char implicitly is unnatural behavior.
> (With the same logic, `ln` should not be implicitly convertible to bool.)
> 

This is sort of the whole point of VRP, and I don't see how you can make it work without crippling it.  The implicit conversion from int (etc) to char is useful and intentional.  Even if you wanted to make 'explicitly' typed declarations differently, these would have to be treated the same:

enum c = 'a' + 1; // no explicit type, but will be inferred as int
enum int d = 'a' + 1; // explicitly typed as int
enum x = "xxx" ~ c ~ d;

--

https://issues.dlang.org/show_bug.cgi?id=14035

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #13 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to yebblies from comment #12)
> enum c = 'a' + 1; // no explicit type, but will be inferred as int

as *integral*, which fits to any integral type. at least that is what ordinary human expects.

--

https://issues.dlang.org/show_bug.cgi?id=14035

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ketmar@ketmar.no-ip.org     |

--

https://issues.dlang.org/show_bug.cgi?id=14035

--- Comment #14 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to yebblies from comment #12)
> This is sort of the whole point of VRP

I think it's a problem in the current implemented semantics of VRP. Applying VRP beyond the "type categories" will introduce human unfriendly behavior.

> The implicit conversion from int (etc) to char is useful and intentional.

It's useful only when it does not break user intentional. Otherwise it would be harmful.

> Even if you wanted to make 'explicitly' typed
> declarations differently, these would have to be treated the same:
> 
> enum c = 'a' + 1; // no explicit type, but will be inferred as int
> enum int d = 'a' + 1; // explicitly typed as int
> enum x = "xxx" ~ c ~ d;

I think above code should be error. If user want to make a character by the expression 'a' + 1, c and d should be declared with char type.

And it will be consistent with runtime code behavior.

auto c = 'a' + 1;
int d = 'a' + 1;
auto x = "xxx" ~ c ~ d;   // Error: incompatible types: 'string' and 'int'

--

https://issues.dlang.org/show_bug.cgi?id=14035

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timothee.cour2@gmail.com

--- Comment #15 from Steven Schveighoffer <schveiguy@yahoo.com> ---
*** Issue 18346 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=14035

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick@geany.org

--- Comment #16 from Nick Treleaven <nick@geany.org> ---
*** Issue 17333 has been marked as a duplicate of this issue. ***

--