[fauigerzigerk]

>Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too

Do you have an example of that? Can't you always "typedef" any particular generic type as a concrete type and work with that going forward?

>Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that can be safely ignored anywhere it isn't used.

I don't see how this is different from concrete types or interfaces. If you change a public API you may have to update callers. If you change internals you don't have to update callers. Perhaps you can show an example to clarify what you mean.

I'm not a huge fan of generics myself, but I think your claim is that generics force you to introduce unnecessary dependencies. I don't see how this is true on a logical level. Dependencies between compiled artifacts are a different matter, but that's an implementation issue and I don't think it's what you're talking about.

[orthoxerox]

https://github.com/dotnet/csharplang/issues/1328

> Have you ever wanted an interface (or abstract type) to be parameterized on a polymorphic variable to its implementer, but not its users? Have you ever wanted to parameterize over internal state, without revealing what that state contains to your users? This is what existential types allow you to do.

[maxbond]

I mentioned in a sibling comment, I just don't wanna write an example, sorry.

You can't typedef, or populate the generic in any way, until you've reached a point in your code where you have sufficient information to know what to populate it with. This can often be further from the point of the initial change than you might like, as I described. (ETA: I didn't realize viral implied that you can _never_ concretize, I only meant there's a tendency to pass it up the chain.)

Changing public APIs will cause secondary changes. Generics are coupled more tightly than some other kinds of changes. For example adding a parameter to a method in an interface does force you to update all those implementations, and then all the usages of those implementations, which is a lot of work and could potentially trigger a similar situation. But generally it doesn't bubble up as high. Because generics are more abstract, it's more difficult to populate that parameter - you're more likely to need to pass the buck by being generic over that yourself, which causes you to update more usages, etc.