ArrayList in .Net standard 2.0

[Kryptos-FR]

Hello,

After a question by a customer about the lack of support for ArrayList in the current PCL profiles and standard (which in my opinion was a good thing), I was actually surprised to see that this collection type was making a comeback in version 2.0 of the standard.

So I got me wondering, what is the rationale of forcing all implementation of the standard to have this deprecated API, especially considering the intrinsic performance issues it has and the fact that it offers no advantage over List<t> (or even List<object>) . Keeping it on Desktop version would make sense for backward compatibility reason (although arguably old code still targeting .Net 1.0 or 1.1 should probably disappear or be ported to a newer version), but for other platforms I really don't see the point.

[svick]

I was actually surprised to see that this collection type was making a comeback in version 2.0 of the standard

Kind of. ArrayList in not part of NETStandard.Library in 1.x, but it exists in the System.Collections.NonGeneric package, which you can already use from .Net Standard 1.3+. You're right that it will become part of .Net Standard proper in 2.0.

Keeping it on Desktop version would make sense for backward compatibility reason, but for other platforms I really don't see the point.

It's exactly the same reason. Backwards compatibility is still important in .Net Standard (and is especially a focus in .Net Standard 2.0). And considering that ArrayList is used by about 12 % of apps and 7 % of NuGet packages it makes sense to include it.

[Kryptos-FR]

And considering that ArrayList is used by about 12 % of apps and 7 % of NuGet packages it makes sense to include it.

Wouldn't it be better to educate people not using it? What does it offer that other collection don't have? Redundancy is an anti-pattern since you have to maintain twice the amount of code. I'm fine to have it as a plugin/extension but not as a first-class citizen of the standard. I doesn't make sense. Or do you really want to have to deal with obsolete legacy code 20 years from now? All legacy should go into a separate assembly with the goal of being removed ASAP.

Otherwise you end up slowing down the adoption of new standard, pretty much like IPv6 which was supposed to replace IPv4 almost 20 years ago (1998)!!

[Kryptos-FR]

And considering that ArrayList is used by about 12 % of apps and 7 % of NuGet packages it makes sense to include it.

Wouldn't it be better to educate people not using it? What does it offer that other collection don't have? Redundancy is an anti-pattern since you have to maintain twice the amount of code. I'm fine to have it as a plugin/extension but not as a first-class citizen of the standard. I doesn't make sense. Or do you really want to have to deal with obsolete legacy code 20 years from now? All legacy should go into a separate assembly with the goal of being removed ASAP.

Otherwise you end up slowing down the adoption of new standard, pretty much like IPv6 which was supposed to replace IPv4 almost 20 years ago (1998)!!

[svick]

Otherwise you end up slowing down the adoption of new standard, pretty much like IPv6 which was supposed to replace IPv4 almost 20 years ago (1998)!!

List<T> is already the new standard, I don't think it needs any help. On the other hand, keeping ArrayList could help the adoption of .Net Standard (by a tiny amount).

[John0King]

And considering that ArrayList is used by about 12 % of apps and 7 % of NuGet packages it makes sense to include it.

Does those apps and Nuget packages target .net 4.6.1+ or even .net 4.5+?
I will be happy if ArrayList is not be included or make it obsolete
The ArrayList and List<object> confuse me for a few weeks when I start to learn C#.

[terrajobst]

We are not going to exclude non-generic collections. In .NET Core v1 we've tried very hard to keep non-generic collections out; but even there we always had it as an optional component for backwards compat. It was a constant battle to keep ABI compatibility of higher-level components (such as networking), which started in the V1 timeframe and used collections that wrap (or sit on top of) the non-generic collections. Since we had to add a ton of APIs back, even more stuff is depending on it somewhere now.

Excluding the API for cleanliness adds very little value:

• The namespace isn't referenced by default (virtually all templates only include System.Collections.Generic)
• Over the years, I've seen virtually zero confusion among developers which types to use
• They don't cause any real bloat

If you have to port existing code, it's quite tedious and error prone to rewrite usages from ArrayList and Hashtable to List<T> and Dictionary<TKey, TValue>. For battle tested code, there is very little to be gained.

[Kryptos-FR]

They don't cause any real bloat.

They do. They cause a lot of unnecessary allocations when used with value types. They need casting when accessing elements. They are not compatible with Linq until you use Cast<object>. They add no value compared to generic collections.

Over the years, I've seen virtually zero confusion among developers which types to use

Maybe because you were only talking to experienced and seasoned developers. There is actually a lot of confusion for new developers and/or people moving from other language such as Java. At least mark them as obsolete so that even new comers will know not to use them.

If you have to port existing code, it's quite tedious and error prone to rewrite usages from ArrayList and Hashtable to List and Dictionary<TKey, TValue>. For battle tested code, there is very little to be gained.

You don't need to port application that already use them. Firstly, those applications are already not compatible with .Net standard as it is today (.Net standard 1.6 doesn't support those collections). Secondly, even if those applications/libraries want to be ported to .Net standard they could still references an assembly that has those types, that is compatible with .Net standard but is not included in the standard. This could be a nuget package. There is no need to have it in the standard.
Let see it the other way around. A new implementation of the standard will need to implement this useless and inefficient collections. That definitely doesn't help the adoption of the standard

[svick]

They don't cause any real bloat.

They do. They cause a lot of unnecessary allocations when used with value types.

I think what @terrajobst meant is that they don't cause bloat when you don't use them. In other words, if you don't use them, then the fact that they exist won't really affect you.

Nobody is disputing that the collections have performance and other issues and that you shouldn't use them in new code.

At least mark them as obsolete so that even new comers will know not to use them.

There is a proposal to create a [Legacy] attribute, which might be more appropriate than [Obsolete]: https://github.com/dotnet/corefx/issues/10093.

.Net standard 1.6 doesn't support those collections

It does. You just have to reference the System.Collections.NonGeneric package.

This could be a nuget package. There is no need to have it in the standard.

Do you think it's appropriate to make for example System.Xml.Serialization part of the .Net Standard? Then you need to make ArrayList a part of it too and it can't be in an separate package. (System.Xml.Serialization.XmlSchemas inherits from CollectionBase which has a property of type ArrayList.)

A new implementation of the standard will need to implement this useless and inefficient collections. That definitely doesn't help the adoption of the standard.

A new implementation could just copy them from corefx. I don't see how does that hurt creating a new .Net Standard implementation.

[terrajobst]

They don't cause any real bloat.

They do. They cause a lot of unnecessary allocations when used with value types.

[@svick] I think what @terrajobst meant is that they don't cause bloat when you don't use them. In other words, if you don't use them, then the fact that they exist won't really affect you.

That's indeed what I meant.

[@Kryptos-FR] This could be a nuget package. There is no need to have it in the standard.

That's what I said above. We can't let non-generic collection sit on top because other APIs in .NET Standard depend on it in API or implementation.

[@Kryptos-FR] A new implementation of the standard will need to implement this useless and inefficient collections.

I don't think anybody in their right mind would implement the standard from scratch. New .NET stacks are built by forking an existing stack (such as .NET Core or Mono). That's what, for example, Tizen and Unity have done.