I tend to use longer names for these (e.g., mainAxisExtent and crossAxisExtent), but I can see the argument for using these shorter names. I'm not sure how consistent we want to be.

I'm happy to use the longer names. done.

We should probably count down and throw an exception if we spin this loop more than, for example, 10 times.

Done

I didn't understand this description. Which line? Maybe add an example?

Fixed.

From the top to where?

Fixed along with the previous one.

Looking at the call site, I see that this function is converting the given parentMainAxisPosition into the coordinate system of the child.

I'd put the up and left cases closer to see the parallelism

reordered down,right,up,left

Why not just mainAxisExtent or extent?

figured it out.

Why a function rather than a getter?

because one of its implementation is O(N) and our design guide says to use methods for expensive getters.

This sounds like it's going to apply a label to a child rather then get a label for the child. Maybe labelForChild ?

done

I'd move up and left to be next to each other to show parallelism

down,right,up,left

same comment about this name.

I wasn't expecting this function to call markNeedsLayout based on the name... Maybe have this function return a bool and have the caller call markNeedsLayout?

Done.

I generally prefer while (true) { ... } infinite loops, but maybe that's not in the style guide (yet).

I really wish Dart had a loop construct that had the following structure:

loop {
  ...;
  break here when (condition);
  ...;
}

size = new Size(constraints.maxWidth, constraints.minHeight) seems more straightforward.

done

Should we have this assert in the "no children" case?

added

I see, this is why you're calling it effectiveExtent in rereportDimensions

I'm surprised that we don't have a version of constrain that takes the width and height separately. Might be worth adding to avoid the extra Size allocation.

Added BoxConstraints.constrainDimensions.

final

done

If this is a member, we don't need to pass the scrollDirection

done

We've been using .. in updateRenderObject functions because it's slightly more efficient and these functions are super hot.

done

Maybe file a bug on me so we don't forget?

I was cleverer. It'll come up when we try to delete the old class names.

I'm slightly suspicious of wanting this in tests but not in real apps, but I guess we'll see.

I was just too lazy to convert the call sites. :-)