"that have discrete values"?

oops, good catch. fixed.

Is there a legitimate use case to allow duplicates? If not I think we should assert?

If we want to assert on duplicates, that's probably something for the engine side. It would be weird to assert here, since there's nothing about the API today that disallows asserts.

I don't have a strong opinion on whether duplicates should be allowed or not.

Ah ok TextStyle's constructor is const.

yeah that's probably the reason we went with this design

Looking at the spec it looks like currently there're only 5 registered axes. Wouldn't it be faster to use regular element look up in a nested loop (or even sort the 2 lists), than doing the allocations ?

Allocations are very cheap in Dart (it just bumps a pointer on the new generation heap).
I think if we expect this codepath to be used frequently enough that we care about performance, we should probably benchmark the various options, though. I don't know what the optimal path is. (I spent some time trying to figure it out, but nothing obvious came to mind.) In practice, I expect most cases will be either empty on one side and not the other (which has a fast path already), or the same order on both sides (which also has a fast path). There's not much benefit to lerping between two different lists (they would just step-function at t=0.5), and if the lists are the same, then it'd be much better for the values to be sorted by the developer than here.

Allocations are very cheap in Dart (it just bumps a pointer on the new generation heap).

Ah TIL but surely setting up the HashSet/Map isn't going to be as trivial right?

I think if we expect this codepath to be used frequently enough that we care about performance, we should probably benchmark the various options

My question was mostly prompted by the O(N) claim in the documentation and the following paragraphs that describe the performance characteristics, and the fast path in the implementation, all that seem to indicate this is performance critical.
If most common cases take the fast path then sgtm (but I found the use of O(N) here a bit misleading since that shows how well the algorithm scales with a large N but in practice the number of font variations in each list <= 5).

yeah it's not trivial (hence the paragraph in the documentation about it). I agree that the constant factors are probably much more important here than the scaling factor. I'll add some more text to that effect to the docs.

Does it make sense to have a default value for each axis then? Like the weight defaults to 400 if one side is null? Or the developer should always make sure the axis pairs match if the lerp function is used for an animated transition?

Fonts have a default value, but we have no way to find out what it is (because, for one, we don't know what font is going to be used, and it could be a different font for each character in the string, due to font fallbacks).

If the developer wants to animate something, they'll specify both ends, in practice.

Ah ok TextStyle's constructor is const.

Allocations are very cheap in Dart (it just bumps a pointer on the new generation heap).

Ah TIL but surely setting up the HashSet/Map isn't going to be as trivial right?

I think if we expect this codepath to be used frequently enough that we care about performance, we should probably benchmark the various options

My question was mostly prompted by the O(N) claim in the documentation and the following paragraphs that describe the performance characteristics, and the fast path in the implementation, all that seem to indicate this is performance critical.
If most common cases take the fast path then sgtm (but I found the use of O(N) here a bit misleading since that shows how well the algorithm scales with a large N but in practice the number of font variations in each list <= 5).