in the common lib there is quite a bit of usage of IReadOnlyCollection where IEnumerable is simpler

[brianpos]

Wondering if there is a purpose of the usage of this type over IEnumerable?
It's forcing a lot of code underneath to be tacking .ToList() on the end of some linq expression, which obviously is doing quite a bit, and if the list isn't needed, you've incurred quite a cost.
The place I've stumbled on it is ChildDefinitions in ElementNode.

https://github.com/FirelyTeam/firely-net-common/blob/445e41f192697b711cf8c6551eae1c9b5c501dcb/src/Hl7.Fhir.ElementModel/Specification/IStructureDefinitionSummaryProvider.cs#L71

https://github.com/FirelyTeam/firely-net-common/blob/445e41f192697b711cf8c6551eae1c9b5c501dcb/src/Hl7.Fhir.Support.Poco/Introspection/ClassMapping.cs#L297

[ewoutkramer]

Although this is not something I have been consistent with (and I am still not sure what is the best solution) I was duly following Microsoft's guidelines here (https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/guidelines-for-collections?redirectedfrom=MSDN#collection-prop[…]d-return-values):

✔️ DO use ReadOnlyCollection, a subclass of ReadOnlyCollection, or in rare cases IEnumerable for properties or return values representing read-only collections.

It also says:

In cases where you are sure that the only scenario you will ever want to support is forward-only iteration, you can simply use IEnumerable.

When I designed this interface, I was positively sure that users of these interfaces would need to do more with the returned list of children than just forward-only iteration, so I moved the responsibility of doing ToList() to the implementor of the interface, rather than the user of the interface.

[brianpos]

Hmm. I'm not sure I like the auto always inflating the collection to a list when it's not needed, it is lots more computation.
(for such an internal core routine)
I'll keep an eye on it when I get to the performance stage of the FML engine.