digitalmars.D.learn - Deprecation: foreach: loop index implicitly converted from size_t to
- Michael (10/11) Jan 18 2019 Hello all,
- Nicholas Wilson (5/18) Jan 18 2019 The reason for the deprecation is that if your array props is >
- Steven Schveighoffer (18/28) Jan 18 2019 That's one possibility.
- Adam D. Ruppe (3/4) Jan 18 2019 Yeah, I agree. But the language is silly. I just leave the type
- Michael (5/9) Jan 18 2019 Thank you all for the concise explanations and suggestions, I
- Jonathan M Davis (22/32) Jan 18 2019 Well, you were really doing the equivalent of simply declaring a variabl...
Hello all, I am getting this deprecation warning when compiling using DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what the problem is, however, because the code producing these warnings tends to be of the form:foreach (int i, ref prop; props)This, to be, looks like quite the explicit conversion, no? Does it mean I now have to use to!int(i) to convert the type of i in a foreach now? Thanks, Michael.
Jan 18 2019
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:Hello all, I am getting this deprecation warning when compiling using DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what the problem is, however, because the code producing these warnings tends to be of the form:foreach (int i, ref prop; props)This, to be, looks like quite the explicit conversion, no? Does it mean I now have to use to!int(i) to convert the type of i in a foreach now? Thanks, Michael.foreach (int i, ref prop; props)All you need to do isforeach (i, ref prop; props)The reason for the deprecation is that if your array props is > 2GB int can't span the range of indices necessary because it will overflow.
Jan 18 2019
On 1/18/19 7:27 AM, Michael wrote:Hello all, I am getting this deprecation warning when compiling using DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what the problem is, however, because the code producing these warnings tends to be of the form:That's one possibility. You can avoid to!int by using a mask or a cast: foreach(_i, ref prop; props) { int i = _i & 0xffff_ffff; auto i2 = cast(int)_i; } It's less than ideal, but the reason is that there is a possibility that props could have 2^31 or more elements, in which case int will not cut it. It's forcing you to make that decision that it's OK vs. the compiler making that assumption. Any time the compiler is throwing away data without a cast, D tends to require buy in from the developer. Note that this is much more of a problem with smaller types (short or byte), but it would be inconsistent not to also flag int as problematic. I would recommend just using foreach(i, ref prop; props) and casting only where it's absolutely necessary. -Steveforeach (int i, ref prop; props)This, to be, looks like quite the explicit conversion, no? Does it mean I now have to use to!int(i) to convert the type of i in a foreach now?
Jan 18 2019
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:This, to be, looks like quite the explicit conversion, no?Yeah, I agree. But the language is silly. I just leave the type out of foreach and explicitly cast it inside the body.
Jan 18 2019
On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote:On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:Thank you all for the concise explanations and suggestions, I think that's fairly straightforward. I thought perhaps I was doing the sensible thing of dealing with the conversion inside the foreach statement, but I guess not!This, to be, looks like quite the explicit conversion, no?Yeah, I agree. But the language is silly. I just leave the type out of foreach and explicitly cast it inside the body.
Jan 18 2019
On Friday, January 18, 2019 8:34:22 AM MST Michael via Digitalmars-d-learn wrote:On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote:Well, you were really doing the equivalent of simply declaring a variable without a cast. e.g. int i = arr.length; rather than int i = cast(int)arr.length; In general, if the compiler treated giving the foreach variable an explicit type as being a cast, it would make it really easy to screw up and unknowingly give a different type than the actual type of the values and end up with an invisible cast, which could cause subtle bugs. IIRC, the only case where foreach treats giving an explict type as anything like a cast is when you're iterating over a string type, and you give a character type different from the character type of the string. In that case, it actually decodes the string from one Unicode encoding and encodes it in the other. Whether the language should have done that rather than requiring that a library solution be used is debatable (I believe that it far predates Phobos having the Unicode handling that it does now), but at least it can't result in stuff like silent truncation. Worst case, it has a silent performance hit, or you get an unexpected UnicodeException at runtime due to invalid Unicode. - Jonathan M DavisOn Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:Thank you all for the concise explanations and suggestions, I think that's fairly straightforward. I thought perhaps I was doing the sensible thing of dealing with the conversion inside the foreach statement, but I guess not!This, to be, looks like quite the explicit conversion, no?Yeah, I agree. But the language is silly. I just leave the type out of foreach and explicitly cast it inside the body.
Jan 18 2019
Why am I forced to visit this D Lang thread, why this deprecation warning still appears in my console window in the latest version of DMD. Does not make any sense from the developer's perspective to show this warning and pollute the already polluted logging entries of the compiler. How am I suppose to program anything effectively if half of the screen are some nonsensical deprecation warnings without guidance or sane explanations. This is not better ``` foreach (i, row; arr) ``` than ``` foreach (int i, row; arr) ``` Hides the datatype and makes the D language appear in-explicit and annoying. What is this language becoming. A completely weak typed language or something? I would use JavaScript if I would want that. How are we suppose to make whole sane Operating Systems with such syntaxes. Do everyone just enjoy having bugs with some implicit size_t, or do everyone just enjoy deprecation warnings in their logging systems when there are way more important problems to solve, that are actually project related.
May 03
On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:Why am I forced to visit this D Lang thread, why this deprecation warning still appears in my console window in the latest version of DMD. Does not make any sense from the developer's perspective to show this warning and pollute the already polluted logging entries of the compiler. How am I suppose to program anything effectively if half of the screen are some nonsensical deprecation warnings without guidance or sane explanations. This is not better ``` foreach (i, row; arr) ``` than ``` foreach (int i, row; arr) ``` Hides the datatype and makes the D language appear in-explicit and annoying. What is this language becoming. A completely weak typed language or something? I would use JavaScript if I would want that. How are we suppose to make whole sane Operating Systems with such syntaxes. Do everyone just enjoy having bugs with some implicit size_t, or do everyone just enjoy deprecation warnings in their logging systems when there are way more important problems to solve, that are actually project related.You can specify the index type, just choose the right one. For now there's a deprecation message but after some while you'll get a proper error message, e.g _"index type for arr must be of type T because arr.length type is T"_. What's is happening now is to help people updating their code and prevent abrupt breakages.
May 03
On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:So how would you update this example, what is the right index type here to choose? ``` import std.stdio : writefln; void main() { auto arr = [ [5, 15], // 20 [2, 3, 2, 3], // 10 [3, 6, 2, 9], // 20 ]; foreach (i, row; arr) { double total = 0.0; foreach (e; row) total += e; auto avg = total / row.length; writefln("AVG [row=%d]: %.2f", i, avg); } } ``` Example taken from https://tour.dlang.org/tour/en/basics/foreachWhy am I forced to visit this D Lang thread, why this deprecation warning still appears in my console window in the latest version of DMD. Does not make any sense from the developer's perspective to show this warning and pollute the already polluted logging entries of the compiler. How am I suppose to program anything effectively if half of the screen are some nonsensical deprecation warnings without guidance or sane explanations. This is not better ``` foreach (i, row; arr) ``` than ``` foreach (int i, row; arr) ``` Hides the datatype and makes the D language appear in-explicit and annoying. What is this language becoming. A completely weak typed language or something? I would use JavaScript if I would want that. How are we suppose to make whole sane Operating Systems with such syntaxes. Do everyone just enjoy having bugs with some implicit size_t, or do everyone just enjoy deprecation warnings in their logging systems when there are way more important problems to solve, that are actually project related.**You can specify the index type, just choose the right one.** For now there's a deprecation message but after some while you'll get a proper error message, e.g _"index type for arr must be of type T because arr.length type is T"_. What's is happening now is to help people updating their code and prevent abrupt breakages.
May 03
On Friday, 3 May 2024 at 14:59:57 UTC, BoQsc wrote:On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:Isn't that obvious ? ```d foreach (const size_t i, row; arr) ``` `arr` is not a static array, it is a dynamic one, consequently its `.length` type is `size_t`, even if you have the feeling that, in the present situation, `int` bitwidth would be sufficient.On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:So how would you update this example, what is the right index type here to choose? ``` import std.stdio : writefln; void main() { auto arr = [ [5, 15], // 20 [2, 3, 2, 3], // 10 [3, 6, 2, 9], // 20 ]; foreach (i, row; arr) { double total = 0.0; foreach (e; row) total += e; auto avg = total / row.length; writefln("AVG [row=%d]: %.2f", i, avg); } } ``` Example taken from https://tour.dlang.org/tour/en/basics/foreach[...]**You can specify the index type, just choose the right one.** For now there's a deprecation message but after some while you'll get a proper error message, e.g _"index type for arr must be of type T because arr.length type is T"_. What's is happening now is to help people updating their code and prevent abrupt breakages.
May 03
On Friday, 3 May 2024 at 15:19:13 UTC, user1234 wrote:On Friday, 3 May 2024 at 14:59:57 UTC, BoQsc wrote:even better: ```d foreach (const typeof(arr.length) i, row; arr) ``` Otherwise I respect your POV, it's just that here I have no problem with the way that works. I dont see any issue with the type system. D type system is static, strong, but optionally inferred. And that's it.On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:Isn't that obvious ? ```d foreach (const size_t i, row; arr) ``` `arr` is not a static array, it is a dynamic one, consequently its `.length` type is `size_t`, even if you have the feeling that, in the present situation, `int` bitwidth would be sufficient.[...]So how would you update this example, what is the right index type here to choose? ``` import std.stdio : writefln; void main() { auto arr = [ [5, 15], // 20 [2, 3, 2, 3], // 10 [3, 6, 2, 9], // 20 ]; foreach (i, row; arr) { double total = 0.0; foreach (e; row) total += e; auto avg = total / row.length; writefln("AVG [row=%d]: %.2f", i, avg); } } ``` Example taken from https://tour.dlang.org/tour/en/basics/foreach
May 03
Well all these proposals to `int` index like `size_t` and `const typeof(arr.length)` are cryptic and less readable and less straightforward in comparison to how it used to be. Feels like horrible decision if the language is suppose to be somewhat futureproof. The `int` was simple, straighforward and great. These suggestions feel like some `C++` all over again.
May 03
A horrible alternative would be to use `alias` on `size_t` to make up a new pseudo-type that is more aligned with the code logic. ``` alias integer = size_t; import std.stdio : writefln; void main() { auto arr = [ [5, 15], // 20 [2, 3, 2, 3], // 10 [3, 6, 2, 9], // 20 ]; foreach (integer i, row; arr) { double total = 0.0; foreach (e; row) total += e; auto avg = total / row.length; writefln("AVG [row=%d]: %.2f", i, avg); } } ```
May 11