Use of bug in `cfor` macro

[nicolasstucki]

The cfor macro accidentally generated the desired code by using a bug in beta-reduction. This bug will be patched scala/scala3#16390 and cfor will need to be updated.

See dotty-staging/spire@7f630c0...99ea909#diff-9cd0f3a9df06a2589472aa8dc960fd2a65a2b65f2f8c257addda1c86ebc31469

[froth]

After staring and printlning for an hour I believe the situation is slightly different.

My opinion is, that the fix in dotty actually fixes a bug in the cfor macro. However the unit test is incorrect and therefore insists on the wrong implementation. I will create a pull request to fix the test.

[froth]

Turned out to be not that straight forward (see closed PR). Maybe someone comes up with a compatible solution.

[erikerlandson]

Out of curiosity, is this why I saw cfor unit test fail when I tried a spire build with 3.3.2?

  + functions with side effects function by-value params in cfor 0.002s
==> X spire.syntax.CforSuite.capture value in closure  0.089s munit.ComparisonFailException: /home/eje/git/typelevel/spire/tests/shared/src/test/scala/spire/syntax/CforSuite.scala:113
112:    }
113:    assertEquals(b1.map(_.apply()).toList, b2.map(_.apply()).toList)
114:  }
values are not the same
=> Obtained
List(
  0,
  1,
  2
)
=> Diff (- obtained, + expected)
 List(
-  0,
-  1,
-  2
+  3,
+  3,
+  3
 )

[armanbilge]

Yes.

[mio-19]

How was the unit test introduced in the first place?

[erikerlandson]

I get the philosophy of maintaining bug-for-bug compatibility, but preventing spire from moving forward, for example #1342, does not seem sustainable.

This has implications beyond just spire deps:

interesting, when I try to upgrade to algebra 2.12, it fails because it requires native 0.5
however I cannot build because spire fails on scala-native 0.5
so I am now currently stuck on scala-native 0.4, and algebra < 2.12

[erikerlandson]

Can we just eat the breaking behavior and bump to 0.19.0 ? Particularly since the "breaking" change is actually a "fixing" change?