Make OrderedDictionaryKeyValueCollection implement IList

[iRon7]

#15843 Ordered Dictionary keys are not numerically indexable

Just to formalize a .Net request originated from a PowerShell issue (The impact is low and I do have several workarounds):

Steps to reproduce

Indexing keys in a hash table does make much sense as the keys are unordered by design.
But are expected to work on an [ordered] dictionary.

$a = [ordered]@{ a = 1; b = 2; c = 3 }
$a.Keys[0] # $a.get_Keys()[0]
$a.Keys[1] # $a.get_Keys()[1]

Expected behavior

# Index 0 return a
$a.Keys[0] # $a.get_Keys()[0]
a

# Index 1 return b
$a.Keys[1] # $a.get_Keys()[1]
b

Actual behavior

# Index 0 returns all keys
$a.Keys[0] # $a.get_Keys()[0]
a
b
c

# Index 1 and successive indices return $Null
$a.Keys[1] # $a.get_Keys()[1]

Error details

No errors (unless strict mode is set)

Workarounds

@($a.Keys)[0]

([object[]]$dict.Keys)[0]

$dict.Keys.ForEach{ $_ }[0]

$keys = [object[]]::new($dict.Keys.Count)
$dict.Keys.CopyTo($keys, 0)
$keys[0]

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
GitCommitId                    7.1.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Suggested solution

Change the return type of IDictionary.Keys to IList

[svick]

This would be a significant breaking change, i.e. any assembly that used this member would stop working on a newer version of the runtime. As such, I seriously doubt this change would be considered.

[iRon7]

This would be a significant breaking change

I was afraid of that and I am not able to oversee the impact here.
From my view (as a PowerShell scripter) the impact appears low. PowerShell is basically loosely language, the current implementation (returning a OrderedDictionaryKeyValueCollection type) is quite useless (in PowerShell). Besides, as PowerShell normally unrolls collections anyways, It probably won't break any existing PowerShell scripts. Meaning: all the given workarounds can be applied multiple times on the OrderedDictionaryKeyValueCollection type without issue. In other words, all the given workarounds (all the known ways to enumerate the OrderedDictionaryKeyValueCollection type in PowerShell) will likely survive a fix.
But I understand that a program written in strict language as C# could simply break on a type definition or comparison.

I will leave it up to you to eventually close this issue as e.g. "won't fix" (or not).

[svick]

PowerShell is basically loosely language, the current implementation (returning a OrderedDictionaryKeyValueCollection type) is quite useless (in PowerShell).

I'm not too familiar with PS, but would changing just the implementation, by making OrderedDictionaryKeyValueCollection implement IList help? Because that wouldn't be a breaking change at all, and so should have a much better chance of being accepted.

[iRon7]

@SeeminglyScience, sorry for reaching out to you...
Can you confirm that making OrderedDictionaryKeyValueCollection implement IList fixes the issue in PowerShell?

[bartonjs]

Changing the return type of IDictionary.Keys would make every existing compiled .NET program (C#, F#, VB, etc) that used it fail with a MissingMethodException (generally when the calling method gets JITted). It's pretty much a "nope, not gonna happen".

It looks like OrderedDictionaryKeyValueCollection could be an IList without too much effort. That would help in certain cases (such as the System.Linq.Enumerable methods) that do a runtime type check to opportunistically do things a faster way. Don't know if it would have any impact on PowerShell usage, though.

[SeeminglyScience]

@SeeminglyScience, sorry for reaching out to you...
Can you confirm that making OrderedDictionaryKeyValueCollection implement IList fixes the issue in PowerShell?

Yep that would enable indexing in PowerShell

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @eiriktsarpalis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

#15843 Ordered Dictionary keys are not numerically indexable

Just to formalize a .Net request originated from a PowerShell issue (The impact is low and I do have several workarounds):

Steps to reproduce

Indexing keys in a hash table does make much sense as the keys are unordered by design.
But are expected to work on an [ordered] dictionary.

$a = [ordered]@{ a = 1; b = 2; c = 3 }
$a.Keys[0] # $a.get_Keys()[0]
$a.Keys[1] # $a.get_Keys()[1]

Expected behavior

# Index 0 return a
$a.Keys[0] # $a.get_Keys()[0]
a

# Index 1 return b
$a.Keys[1] # $a.get_Keys()[1]
b

Actual behavior

# Index 0 returns all keys
$a.Keys[0] # $a.get_Keys()[0]
a
b
c

# Index 1 and successive indices return $Null
$a.Keys[1] # $a.get_Keys()[1]

Error details

No errors (unless strict mode is set)

Workarounds

@($a.Keys)[0]

([object[]]$dict.Keys)[0]

$dict.Keys.ForEach{ $_ }[0]

$keys = [object[]]::new($dict.Keys.Count)
$dict.Keys.CopyTo($keys, 0)
$keys[0]

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
GitCommitId                    7.1.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Suggested solution

Change the return type of IDictionary.Keys to IList

Author:	iRon7
Assignees:	-
Labels:	area-System.Collections, untriaged
Milestone:	-