This is part 2 of our analysis of the .NET API review meeting for January 14th. This report covers HashSet, RegEx, Process.Start, Immutable collections, and BitVector32.
[Video] GitHub Issue: #382: Add ctor to HashSet<T> that allows the initial capacity to be specified
No debate on this one, though may wonder why it wasn’t supported in the original version.
[Video] GitHub Issue: #304: Regex should provide a validation method
Currently the RegEx parser uses a fail-fast model. Which is to say, if there are multiple errors in a regex string, only the first error will be reported and the process is immediately aborted.
The crux of proposal is that more information is desirable. Ideally, it would return a collection of errors showing all of the problems in the regular expression. But this requires that the parser try to recover from errors so that it can continue to parse the rest of the expression and look for other errors.
One concern is that if this is honored, the next thing people will want is support for custom highlighting, code completion, etc. so that it can be used in Roslyn. This is far beyond the scope of the API, so they are worried offering this would be inappropriate given that a new API is going to be needed either way.
Conclusion: Separate the two proposals.
One proposal is to improve the information available in the exception that RegEx throws during a parse failure. This would just include basic information such as the location of the first error if that doesn’t require too much rework.
The second proposal is whether or not to TryParse versions of the methods.
The RegEx API won’t be extended to the point where it can support IDEs.
[Video] GitHub Issue: #311: Bring back Console.CancelKeyPress
This proposal is simple, just take the method that already exists in the Windows desktop version of .NET and port it over to the cross-platform version of .NET. Barring any compatibility issues, this is essentially just going to be copy and paste from the original version.
[Video] GitHub Issue: #306: Make Process.Start have a option to change handle inheritance
On the surface, the problem seems simple. In Windows, handles can be inherited by child processes. This can lead to unintended consequences such as Notepad holding open a TCP socket after the parent application tries to close it. This new flag would simply give the user the option to not inherit handles.
The wrinkle here is that this design doesn’t make sense in Linux. While Windows has a global setting when the child process is created, Linux allows you to specify whether or not each handle is inheritable when the handle is created.
One proposal is to offer a tristate property for handle inheritance: OS default, inherit handles, and don’t inherit handles.
Another proposal is to create a basic version of ProcessStartInfo that only offers cross-platform options. Then create subclasses to expose Linux, Win32 and Windows Shell Execute specific functionality.
Conclusion: Offer the new property that uses the existing two-state HandleInheritability enumeration.
[Video] GitHub Issue: #318: Proposal for ImmutableInterlocked.ApplyChange API
To alter an immutable collection in a thread safe manner, you have to get a reference to the collection, create the replacement list, then use Interlocked.CompareExchange to see if you can successfully replace the list. If another thread overwrote the collection in the meantime, that method will return false and you will have to start the whole process over again.
The ImmutableInterlocked class simplifies this process for basic operations such as adding and removing items. You still need to call it in a loop, but you don’t need to deal with local variables.
This proposal would simply add a generic version that accepts a lambda for the operation to be performed. Technically this would make the other versions redundant, but since they already shipped, they can’t be removed.
Conclusion: The new method would be added.
There was a question as to whether or not the redundant methods would be marked as obsolete.
Conclusion: Since the redundant methods are not broken, they shouldn’t be deprecated.
[Video] GitHub Issue: #373: BitVector32 should implement IEquatable<T>
BitVector32 exposes an integer as an array of bits and small integers. It is part of the System.Collections.Specialiazed namespace, which is generally considered to be legacy and untouchable by the Base Class Library team.
Related this this is the BitArray class. If BitVector32 isn’t considered to be legacy, then it should be reconciled with the functionality found in BitArray.
No conclusions were reached on this proposal and it will be revisited on a later date.
