On Thursday, November 30, 2023 7:31:42 AM MST bachmeier via Digitalmars-d wrote:
> On Thursday, 30 November 2023 at 11:54:01 UTC, IGotD- wrote:
> > On Thursday, 30 November 2023 at 11:01:15 UTC, Hipreme wrote:
> >> That is because there is no reason to have explicit conversions everywhere, they are overly verbose and ugly. And this is one of the reasons because I don't use `foreach` in my code. Good old `for` loop can let you decide the type. Modern programming languages should reduce friction, and not increase it.
> >
> > One of the corner stones in D is that there are hardly any implicit conversions. I not saying personally against it but it is one of the main D "features".
>
> Do you have an example where it can cause problems in this case?

The main place that using int with the index for foreach would cause problems is if you're programming on a 32-bit system and then later start compiling that code on a 64-bit system.

Because size_t is uint on 32-bit systems, using int with foreach works just fine aside from the issue of signed vs unsigned (which D doesn't consider to be a narrowing conversion, for better or worse). So, someone could use int with foreach on a 32-bit system and have no problems, but when they move to a 64-bit system, it could become a big problem, because there, size_t is ulong. So, code that worked fine on a 32-bit system could then break on a 64-bit system (assuming that it then starts operating on arrays that are larger than a 32-bit system could handle).

If the implicit narrowing conversion is forbidden with foreach (like it is pretty much everywhere else in the language), and you used int or uint for the index, then when you go to compile that code on a 64-bit system, then you'll get a compiler error, and you can then fix the code as appropriate, whereas if we allow it to be int or uint and treat it like an explicit cast, then you have a silent bug.

And because there wasn't actually an explicit cast involved, you can't even grep for the cast keyword. There's also no way to tell at a glance whether the programmer purposefully used int knowing that the conversion would take place or whether they just used int because that worked for what they were doing on a 32-bit system but then didn't work later on 64-bit systems (and of course, if the code worked with int on a 64-bit system originally doesn't mean that it will later, since the code that generates the array could later be changed and allow much larger arrays than was originally the case).

Of course, if you're using int instead of uint, then you actually still risk bugs on 32-bit systems if the array is large enough (depending on what exactly is done with the index), but the core idea of disallowing the implicit conversion with foreach is to force the programmer to deal with the issue rather than silently having code that could have an index that's larger than the type being used can actually hold.

Now, the question then is how likely that particular bug is vs someone purposefully using int on a 64-bit system, because they wanted int, and they didn't think that there was any way that they would be operating on an array that's larger than int.max or uint.max in length. Outside of operating on large files and "big data," there probably aren't a lot of programs that are going to have arrays large enough that int won't be enough to index them, so there will be a lot of code which could use int with foreach and have no problems whatsoever. And clearly, there are folks who have used int with foreach in the past and had no problems with it, so they're annoyed at being forced to use size_t instead.

Personally, I tend to lean towards the pendatic approach here and think that anything and everything involving indexing should be using size_t so that it will work across architectures and not have bugs due to casting to smaller types, but obviously, smart people can disagree on the issue. It's not like allowing int in foreach is wrong across the board. It's just that it can cause a particular class of bugs, and arguably, it's an implicit conversion rather than an explicit conversion, which goes against how D's type conversion rules normally work. But it's also the case that using int in foreach was allowed and treated as an explicit cast for years.

So, I think that the change to requiring size_t was a good one, but I can also see why some folks would get annoyed by it, and it's a much bigger deal than it would have been otherwise, because the behavior was changed rather than it always having required a type that size_t can implicitly convert to.

- Jonathan M Davis

On Thursday, 30 November 2023 at 15:25:52 UTC, Jonathan M Davis wrote:

> And because there wasn't actually an explicit cast involved, you can't even grep for the cast keyword.

grep 'foreach(int'