Levi Broderick GrabYourPitchforks

Problem summary

While working on the System.Text.Encodings.Web refactoring I noticed that we have several duplicates of the System.Text.Rune type (or its backing logic) throughout our projects.

The official implementation exposed by System.Runtime:

https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Text/Rune.cs

A copy used by the Utf8String OOB:

https://github.com/dotnet/runtimelab/blob/feature/Utf8String/src/libraries/System.Utf8String.Experimental/ref/System.Utf8String.Experimental.Rune.cs

Draft function pointers in reflection spec

Passing function pointers as parameters to `MethodInfo.Invoke`

The reflection stack should treat function pointer arguments as standard pointer arguments for the purposes of method invocation. This means that boxed IntPtr arguments should be accepted as parameters to these methods in MethodInfo.Invoke scenarios. For methods which return function pointers, they should be returned as boxed IntPtrs.

The reflection stack, for convenience, should also consider allowing developers to pass System.Reflection.Pointer instances as input arguments to these methods.

Inspecting function pointer types

Problem statement and core scenario

We want to introduce the idea of a value type where the underlying data is only ever "live" in at most one place. The canonical example is the internal ValueStringBuilder struct type, which performs internal ArrayPool management.

ValueStringBuilder builder = new ValueStringBuilder(); // VSB is a struct type
builder.Append("foo");
builder.Append(obj);
HelperMethod(ref builder); // builder passed by ref to helper methods
return builder.ToString(); // ToString releases underlying rented arrays back to pool

Improving the developer experience with regard to default string globalization

Note: This is a companion document to dotnet/docs#21249, which discusses the behaviors as they currently exist. It's assumed the reader is generally familiar with that document.

Summary

Since .NET 5 standardized on using ICU instead of NLS for globalization across all supported platforms (see breaking change notice), we've received a few reports of string and globalization APIs not behaving as expected.

These reports generally fall into one of two buckets:

	using System;
	using System.Buffers;
	using System.Diagnostics;
	using System.IO;
	using System.Runtime.InteropServices;
	using System.Runtime.Intrinsics;
	using System.Runtime.Intrinsics.X86;
	using System.Text;
	using System.Text.Unicode;
	using BenchmarkDotNet.Attributes;

	public sealed class PublicKeyToken : IEquatable<PublicKeyToken>
	{
	public PublicKeyToken(byte[] publicKeyTokenBytes);
	public PublicKeyToken(ReadOnlySpan<byte> publicKeyTokenBytes);
	public PublicKeyToken(string publicKeyTokenHexString);
	public PublicKeyToken(ReadOnlySpan<char> publicKeyTokenHexString);

	public ReadOnlySpan<byte> RawBytes { get; }
	public string TokenString { get; }
	public byte[] GetPublicKeyTokenBytes();

	using System;
	using System.Runtime.InteropServices;

	namespace FieldOffsetSample
	{
	class Program
	{
	static void Main(string[] args)
	{
	MyStruct myStruct = default;

	using System;
	using System.Collections.Generic;
	using System.Reflection;
	using System.Text;
	using System.Linq;
	using System.Diagnostics;
	using System.Runtime.CompilerServices;

	namespace ConsoleAppDumpCryptoApis
	{

	using System;
	using System.IO;
	using System.Runtime.Serialization;
	using System.Runtime.Serialization.Formatters.Binary;

	class Program
	{
	static void Main(string[] args)
	{
	Stream inputStream = GetInputStream();