As far as op constraints in generics are concerned, I’ll need to have word with my .NET colleagues all of whom seem to be labouring under a misunderstanding of .NET generics.

(I don’t doubt you - a quick google seems to confirm that op constraints are also not supported in .NET)

Thanks for taking the time out to work up this series of posts.

You mention that neither Tlist nor TEnumerable implement IEnumerable in the RTL.

Would this be hard to add as a modification to a local version of the RTL source?

Yes, I know everyone will say that will break things in deployed and third party packages etc, and they’d be right. But we don’t use packages, and we recompile from source all our third party components so, so it’s not a problem for us

Raymond.

Regarding why Average returns T and not Double (or better still, R, an arbitrary result type), I explained that in the post:

In order to make the code I’m going to show simpler, I’ll use the same type argument for the input and output. In other words, if the function is passed a list of integers, it will return the average as an integer. If it’s passed a list of doubles, it will return the average as a double. This is probably not ideal for a general-purpose statistical library, but, for the purposes of this demo, it makes the code quite a bit easier to understand.

Raymond asked for a demonstration of something like MapReduce. I’m happy to oblige, but it’s already turning into one of the longest answers to a question that I’ve ever posted on this blog. So I’m trying to steer around features like this which would make it even longer.

Too many concrete applications of generics, outside of simple containers, would seem to require a greater richness than Delphi 2009 generics currently provide.

I’m beginning to think that an approach based more on C++ templates would have been preferable (or at least a useful addition, if not instead of).

A slight tweak to the syntax might yet enable this:

Average(aData: IEnumerable): Double;

For which:

Average(..);

would be fine but

Average(..);

would fail to compile (when the compiler attempts to emit : sum of strings divided by number of strings).

The operator constraints approach could deal with things in this case more cleanly though:

Average(aData: IEnumerable): Double;

This is an off-the-cuff speculation at the sort of contraints specification that might be needed (i.e. T supports Addition of T yielding T and division by T yielding Double).

Assuming that Addition and Division indicate the calculation of a mean average, the result is surely a floating point of one form or another, not T. I’ve simply opted for Double in my decls above.