David Heffernan

Yes, this should be a read only property. In an ideal world we'd have proper language support for references, as I think is especially we done in D foreach (ref elem; arr) { elem = 0; }

TList<T> FWIW my codebase doesn't use the RTL generic collections. It uses a collections library that I wrote, that amongst other things has collection classes that allow access to items via references to the underlying records for exactly this situation. I think that you are making valid points, but you aren't pinning the blame in quite the right place. I don't think the issue is with value types per se. To my mind the issues are more about limitations of the standard RTL collection classes.

Not if you use a collection that provides you access to items via references to the underlying records

That is correct. But that's not the point you made.

Files are a special case of streams. And they are orthogonal to collections of strings. A string list is the wrong class for key/value pairs. I don't think you need string list interposers for any of these things.

That's true of course, but the problem arises the moment you use a single third party component.

You just put them in a designtime package, install it, and then use them. That's what I do. I don't find it at all onerous.

Yes. No, it's no trouble at all.

This is the SO post: https://stackoverflow.com/questions/63823156/using-delphis-trichedit-is-there-a-way-to-set-up-a-link-so-someone-can-click I can comment Remy's answer in the dupe, which I am using to good effect: https://stackoverflow.com/a/42536393/505088

We don't need a topic or any examples. We all know that records can be used as generic types.

You can use records and classes with generics.

Really? How are the records allocated? And if you could do that, why couldn't you do exactly the same with a dictionary. Which is my original point. If you can't use a dictionary with records, then I don't see that you can use any collection with records.

How is it any different from holding them in TList<T>?

It depends on how you want to access the data. This isn't really related to associate array style access by key. The issues with value types and copying apply equally to all containers.

Why not? Surely the answer is the same as for objects. If you use a dictionary for objects, why not a dictionary for records?

This issue is covered explicitly by the documentation: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Structured_Types_(Delphi)#Dynamic_Arrays

But your code can only be used for arrays of byte. Stefan is demonstrating generic code.

What does this offer over what Stefan posted in his article?

I'd be surprised if converting from VCL to FMX was simple enough to be usefully automated.

Why would there be conflicts in files that you have not modified? My advice to you is that before you try to change the process to fix the problem, you make sure that you have fully diagnosed the problem.

If you are not working in A, B and C then you simply should never see any conflicts. My guess is that someone in your organisation is using git incorrectly. No reason at all that you should have any troubles with all this in a single repo.

Oh. I took that to mean you want one repo for each of the 850 different variants.

850 repos for every client specific variation sounds kinda crazy. I suspect that you aren't getting great feedback here because your organisation's work flow is, er, unique.

Read Andy's comments to my answer in the SO post. If you care about performance, measure it.

No reason to give any credence to that comment. Ignore it and move on. Be happy that your code is not limited to text that can be encoded with whatever ANSI locale the machine it runs on is using.