[Issue 17336] Implicit type conversion of size_t.init to int causes standard type compatibility test to break

[via Digitalmars-d-bugs]

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

Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |schveiguy at yahoo.com
         Resolution|---                         |WONTFIX

--- Comment #6 from Steven Schveighoffer <schveiguy at yahoo.com> ---
The VRP is definitely not wrong. You are getting exactly what you asked for:
can you add size_t.init to B (yes, due to VRP), and is the result convertible
to B (yes).

The question is, what is the "right" way to do this. I understand that "I want
an instance of a size_t for type purposes" generally is done with size_t.init.
However, clearly this doesn't work out too well. I think using size_t.max is a
good compromise, especially when you know the type being checked is a primitive
and defined to have a max property.

Note that most of the cases are template constraints on a function, and you
have at your disposal the function's parameter instead of reaching for T.init.

Think about what you are asking here, you want size_t.init NOT to convert via
VRP to int (e.g. "let's break everyone's code"), OR you want it to not convert
inside static tests (e.g. "let's break lots of code in a super-inconsistent
way"). I think you can understand that we absolutely can't fix this. What has
to change is the pattern used to check for adding a type.

Perhaps the best thing is to create a set of std.traits.canX (where X is add,
multiply, etc) which checks for operations given two types in the verbose way.
Feel free to file an enhancement for Phobos on that.

Little traps like this are very good to document and publish. I've had quite a
few is(typeof(...)) contraints/checks blow up on me.

--