Yeah. It's definitely not idea, especially with no caching of name lookups in CustomData. Adding cyclic as an argument doesn't feel great either though, since that allows the user to potentially access bad values for those last floats.

I wonder if we can make ->cyclic() fast enough that calling it here isn't unreasonable. Here are two more options though:

A function in the bke::curves namespace

namespace blender::bke::curves {
IndexRange lengths_range_for_curve(IndexRange points, int curve_index, bool cyclic)
{
  return ...
}

I'm not sure about that though. The other stuff in the bke::curves namespace seems almost general enough that it could move to blenlib, but this is a bit more specific to CurvesGeometry.

A static method on CurvesGeometry

static CurvesGeometry::lengths_range_for_curve(IndexRange points, int curve_index, bool cyclic
{
  return ...
}

I think I prefer this method?

I think I was copying the logic from existing curve code, but I also can't think of a fundamental reason, at this level.
At a higher level, for a two point poly curve, cyclic might not make sense since since it can't be reflected visually.

Good point, I adjusted the comment. And the function expects the count to be greater than zero so I added that too.

Good idea! It's implicitly tested in the "expected" values, but I added an explicit check for uniform lengths to a couple of them too. (the distances between consecutive sampled points in Cartesian space aren't necessarily uniform in the general case).

I added that as a "does this compile" test, but I might as well! :)

Honestly I don't remember the reasoning well enough to document it. I'll just remove that 2 point check for now I think. If it becomes a problem we can add it back.

I avoided the repeat division here, that might be an improvement.

I looked into the other comments for a while and didn't find a nice solution though. Anything I added to change to using a for loop significantly increased the complexity, and also requires more processing with epsilons, etc.
As far as I know, the current method with less than or equal comparison is fairly solid, at least it's been tested with current curve code a fair amount.

I can continue looking into this if you feel strongly, right now I'd prefer to keep this as is though, if it's okay with you.