David Heffernan

That trade off depends on the size of the record. For small records then performance is better if the items are stored directly in a contiguous array.

OK, this is making more sense to me, and I can better appreciate the inconvenience.

Maybe. I guess I might not be encountering the problem regularly. You must be facing it very regularly I guess. Isn't that a different issue?

You are massively overstating this. Finding a file from disk is not difficult. Yes it takes a few seconds, but then it's not like this issue happens regularly. Every feature takes resources to implement. Given the immense problems that the entire Delphi product has, I for one would be disappointed if Emba spent resources on features like this that bring so little benefit.

Doesn't seem to me like this is a very significant problem given that you can just open the file in a text editor yourself.

Not sure the IDE should do that. There are tools to convert. If you want to convert, then use those tools. If the IDE did this automatically then that would be painful for people who wanted to use binary.

If it is in binary form then presumably there would be no need because there would be no problem in it

Well, you avoid some of the issues, but not all. For instance you don't avoid the issue where an item is deleted, but a stale pointer is retained. Additionally you end up with a large number of heap allocations, and memory that can be scattered which can impact performance.

Granted the indirection that is offered by a reference type does make some of the issues hard to trip over, but they still exist.

In a collection which owns its members then removing an item leads to a stale reference in either scenario (classes vs records).

Your third sentence directly contradicts the first sentence.

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.