Unsafe.As<TFrom, TTo> should be further constrained

[GeeLaw]

According to expert opinions in #111049, Unsafe.As<TFrom, TTo> is undefined if

• TFrom is value type and TTo is reference type, or
• TFrom is reference type and TTo is value type.

When TFrom and TTo are both reference types, the scenario is covered by Unsafe.As<T>.

Incorrect usage should be prevented by the type system as much as possible, i.e., the constraint should become

public static ref TTo As<TFrom, TTo>(ref TFrom source)
  where TFrom : struct, allows ref struct // currently, only "allows ref struct"
  where   TTo : struct, allows ref struct;

Further Question. It's interesting to know whether reinterpreting between two non-unmanaged structs is undefined. If so, the constraint should be changed from struct to unmanaged.

Updated. See comment 2.

[huoyaoyuan]

Narrowing constraint is breaking change and can never happen.
In corelib there are specific usages to treat GC references as raw pointers, e.g. Unsafe.As<Class, IntPtr>:

runtime/src/libraries/System.Private.CoreLib/src/System/Span.cs

Lines 282 to 285 in dae8909

	if (RuntimeHelpers.IsReferenceOrContainsReferences<T>())
	{
	SpanHelpers.ClearWithReferences(ref Unsafe.As<T, IntPtr>(ref _reference), (uint)_length * (nuint)(sizeof(T) / sizeof(nuint)));
	}

[GeeLaw]

"Breaking change" is not solid enough to prevent a safety change. See https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/9.0/type-instance

The CoreLib usages are an implementation detail, which can take full knowledge of what the current implementation permits. If it uses an undefined, yet happens-to-work-on-this-version, fact, then it should be encapsulated in an internal class, even if its implementation is identical to another public interface. The public interface should be sanitized so that: (1) it is capable of expressing what is intended to work and be exposed; (2) it works in some situations; (3) there is no further proper constraint satisfying (1) and (2); i.e., the interface is maximally sanitized.

[huoyaoyuan]

"Breaking change" is not solid enough to prevent a safety change. See https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/9.0/type-instance

Source breaking change can never happen because it will cause InvalidProgramException. Even if the public functionality would be restricted, it can only throw in its implementation, the constraint can't be changed.

[GeeLaw]

It's good when it breaks the source --- when the user recompiles, they learn the code is incorrect. What's less acceptable is a binary break. I just tried what happens when a generic constraint is changed and no longer satisfied. An exception of type VerificationException is thrown, not InvalidProgramException, if

• the code contains calls to specific types that violate the new constraint, or
• the code is generic, and the generic parameter is not sufficiently constrained to satisfy the new constraint.

The first case is acceptable and desired since UB includes getting an exception. The second case is unacceptable because the actual usage might have not incurred UB. Therefore, you have a point in not narrowing the constraints.

[huoyaoyuan]

It's good when it breaks the source --- when the user recompiles, they learn the code is incorrect.

BCL of .NET Core doesn't ever do this. A new analyzer warning such usages can be introduced, but users must be able to compile the existing source code as-is.

[GeeLaw]

Previous comment raised the concern of breaking verification even if no actual usage leads to undefined behavior.

The new proposal is to change its implementation to

public static ref TTo As<TFrom, TTo>(ref TFrom source)
  where TFrom : allows ref struct
  where TTo : allows ref struct
{
  // Only using what dotnet/runtime#111049 says.
  // This allows class <-> class reinterpretation.
  if (typeof(TFrom).IsValueType ^ typeof(TTo).IsValueType)
    // Localized message...
    throw new NotSupportedException("Reinterpreting between value types and reference types entails undefined behavior.");
  // ldarg.0
  // ret
}

The check is JIT intrinsic (see #12248) so it creates no run-time overhead for defined usage.

[huoyaoyuan]

Incorrect usage should be prevented by the type system as much as possible

This statement is also questionable. In the explicit Unsafe area, it's intentionally allowed to do many sort of unsafe things that are close to implementation details. There are also other ways to do such UB in unsafe code, for example (int*)&classType (allowed in unsafe context of C#).

According to expert opinions in #111049, Unsafe.As<TFrom, TTo> is undefined if

It's still discussed recently. It may need more detailed explanation of undefined-ness.

[GeeLaw]

Unsafe is not the same as undefined/incorrect. It's just unverifiable. Unsafe.As produces perfectly defined result in many cases. If something is already known to be undefined/incorrect and the type-system way to exclude it is not complicated, it should be excluded using type system.

It may need more detailed explanation of undefined-ness.

If we take it as undefined, there's no point is further specifying its semantics since any semantics means "not undefined".