Unsafe Accessors

[TonyValenti]

I don't have a .net 8.0 environment so I can't test this out but I have a few questions about this:

1. Do parameter names have to match?
2. If I have a mismatch and try to access a private member that does not exist, is it a runtime or compile time error?
3. Is this zero overhead?
4. Does this potentially enable scenarios like: ThirdPartyLibrary.SetIsLicensed(true)
   ?

[CyrusNajmabadi]

These are not csharplang questions. This is not part of c# (the language or Roslyn). I recommend maybe asking the runtime.

[DavidArno]

Do parameter names have to match?

No. The signature needs to match (return type and types of the parameters), but the parameter names aren't important.

If I have a mismatch and try to access a private member that does not exist, is it a runtime or compile time error?

Everything with this feature is a runtime error. If you do not specify extern static and just use extern, you get a System.BadImageFormatException: 'Invalid usage of UnsafeAccessorAttribute.' exception. If you try to access a method that doesn't exist, or specify different parameters, you get a System.MissingMethodException: 'Method not found: 'SomeClass.M'.' exception.

Hopefully with .NET 9 (as it's probably too late to get squeezed in before the .NET 8 release), analyzers will be added by the authors of this feature that report such errors at compile-time.

Is this zero overhead?

The proposal (dotnet/runtime#81741) suggests so. It talks about "compile time", but the C# compiler doesn't seem to be involved. Maybe this is an AOT or JIT thing? What's new in .NET 8 doesn't appear to mention it. This is part of the problem with such changes: it affects how we write C# code, but because the language spec doesn't change, it only gets accidently mentioned here. But it doesn't seem to get mentioned as a runtime change either. If it wasn't for someone asking about compile time reflection a few days ago, it could have been months before I stumbled across anything about this feature.

Does this potentially enable scenarios like: ThirdPartyLibrary.SetIsLicensed(true)?

That was always possible via reflection. This just simplifies it.

[TonyValenti]

I actually thought this was a new compiler feature but I asked the above questions in the runtime and it is JIT related, not C#.

I would actually love it if this feature was "migrated" to C# as it might allow compile time resolution instead of JIT-time resolution.

[jnm2]

Compile-time resolution isn't possible by design because the compiler only sees reference assemblies, for the BCL itself and for any NuGet package that contains reference assemblies.

Also, even if not for reference assemblies, there are times when something newer is loaded at runtime than was requested. If A depends on B which depends on C, and A depends on a newer C than B was compiled for, then B can't really have compile-time safety against failures to find things in C.

[HaloFour]

An analyzer could always provide some feedback as to whether or not the members you are attempting to resolve do or don't exist, but I think it's important to note that this kind of integration is and will always be extremely brittle.

[markusschaber]

I think this feature should only be used in limited Scenarios like Code Generation, or white box unit tests to verify private members. In both cases, there's a tight coupling between the involved classes.