Add DynamicallyAccessedMemberTypes::NonPublicDefaultCtor

[marek-safar]

The default constructors are used via reflection quite often. Right now we have no way to mark any default constructors only. It'd be useful to have it as there are code pattern in SPC which are overmarking types because of this.

The closest pattern today is

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor | DynamicallyAccessedMemberTypes.NonPublicConstructors)]

@vitek-karas

[vitek-karas]

How common is this - most reflection APIs only work with public default .ctors.
I understand that this is in corelib, so it affects every app, but I would like to avoid adding new public API (effectively) just for 2 or 3 cases in corelib.

[marek-safar]

Is there any alternative? This seems to be very cheap to implement in the linker and we could hide it with special code inside enum if necessary but why if we do have the implementation.

[vitek-karas]

We could make these couple of places intrinsics.
Why?: If it's really only going to be used from CoreLib (which is pretty likely) then why not hide it

[MichalStrehovsky]

Out of curiosity - what are the places that need this?

The places I know of are in the "runtime magic" category that wouldn't be possible to annotate (like p/invoke for blittable classes, or safehandles).

[marek-safar]

This seems to be mostly used for things that know what type to instantiate and don't want to use Activator (e.g. for performance reasons).

[MichalStrehovsky]

This seems to be mostly used for things that know what type to instantiate and don't want to use Activator (e.g. for performance reasons).

You mean places like CreateInstanceForAnotherGenericParameter? Those don't run any constructors.

Activator has been recently tuned to be very fast so the internal need for special private APIs will be going away.

The exact use cases would definitely help to see if there's any alternatives.

The PublicParameterlessConstructor has been added to the enum because it closely mirrors what the most common activator APIs (and the new() constraint) does. Basically all the values that are currently there are there to match the reflection API shape.

[vitek-karas]

@marek-safar do you have a use case for this? I'm leaning towards just closing this.

[marek-safar]

I think we changed the affected code because of this limitation to use public constructors but there are still cases like

https://github.com/dotnet/runtime/blob/c2f559cf0d41cc099c8f34e50a68021b4fc0ef8e/src/libraries/System.Data.Common/src/System/Data/DataSet.cs#L1101

which might be worth addressing

[vitek-karas]

I find this relatively corner case requirement. The DataSet example is valid, but it's relatively weird (the DataSet itself has public parameterless .ctor, so this only applies to derived types, not sure how common it's there).

The downside of doing this is that it requires adding a new public annotation (basically public API) and support it everywhere. The number of use cases seems really low for that.