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.

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.

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

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

On 4/17/2016 2:29 AM, 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.

Making weird special cases usually winds up having unintended bad consequences in the future, leading to ever more special cases and complexity.

Some solutions you can use:

1. size_t index = str.indexOf("something")

2. auto index = str.indexOf("something")

3. compile for 64 bits as the default

4. regularly compile for 32 and 64 bits

My experience is that over time one gets used to writing 32/64 bit portable code naturally, and the minor irritations don't happen anymore. D isn't a language that tries to hide the differences, and one should be aware of them.

On Sunday, 17 April 2016 at 11:26:02 UTC, Walter Bright wrote:

> My experience is that over time one gets used to writing 32/64 bit portable code naturally, and the minor irritations don't happen anymore. D isn't a language that tries to hide the differences, and one should be aware of them.

Agreed. Before I joined the modern world and bought a 64-bit machine three years back, any D source I made available almost always attracted PRs changing uint to size_t. These days, I regularly compile for both and haven't hit such an error in a long, long time.