Somehow give a warning when trying to assign a size_t/ptrdiff_t to int or uint

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 17, 2016 09:51:07 WebFreak001 via Digitalmars-d wrote:
> On Sunday, 17 April 2016 at 09:38:33 UTC, Temtaime wrote:
> > On Sunday, 17 April 2016 at 09:29:33 UTC, WebFreak001 wrote:
> >> It's annoying to fix all these `int index =
> >> str.indexOf("something")` to size_t/ptrdiff_t because you
> >> started writing the code thinking that indexOf returns an
> >> integer even though it returns a ptrdiff_t. When porting code
> >> from 32bit to 64bit you need to fix all these lines which can
> >> quickly become quite complex from functions where you don't
> >> expect them to return size_t or ptrdiff_t
> >>
> >> Adding a warning when trying to do something like `int i =
> >> funcReturningPtrdiff();` would make porting easier because you
> >> would already spot the issues on the OS/architecture you are
> >> working on. This also affects porting windows to linux as DMD
> >> on windows uses 32bit by default and on linux it uses the
> >> architecture you downloaded as default.
> >
> > There already was a such bugreport.
> > size_t is simple alias to int/long depending on the platform.
> >
> > So currently it's impossible without adding a new type in the
> > frontend.
>
> The compiler has the name of the alias and probably also the
> origin of it. So just checking if its from object.d (or where it
> comes from) could set a boolean "actualSize" or something like
> that to true and then it could use that information somehow

Regardless, at present, size_t is simply an alias, and there's nothing
special about it except that it's defined in object.d, so every D program
will have access to it without importing anything. In order for it to
provide any warnings about how size_t might change across architectures, the
compiler would have to be changed to understand size_t as more than a simple
alias. It's been brought up before, but IIRC, Walter was against the idea,
and his solution was that you should just compile on multiple architectures
if you care. Anyone who wants such a change is going to have to convince
Walter that it's worth it, and I have no idea how easy it would be to
convince him.

Personally, I don't particularly care, because it's not a problem that I've
had. From what I can tell, as long as you actually use size_t and auto like
you should, this sort of issue really doesn't come up much. It mostly bites
folks who just blindly used int for stuff like length. And it _is_ easily
caught if you just compile for multiple architectures. But feel free to try
and convince Walter that it's a big enough problem to merit changing how
size_t is handled.

- Jonathan M Davis