-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What's new in .NET 8 Preview 2 #8134
Comments
System.Reflection: introspection support for function pointersThis feature adds the capability to obtain function pointer metadata including parameter types, the return type and the calling conventions. Previously, the A function pointer instance, which is a physical address to a function, continues to be represented as an This new functionality is currently implemented in the CoreCLR runtime and in For more information, see the API issue and Design. An example using reflection: FieldInfo fieldInfo = typeof(MyClass).GetField(nameof(MyClass._fp));
// Obtain the function pointer type from a field. This used to be the 'IntPtr' type, now it's 'Type':
Type fpType = fieldInfo.FieldType;
// New methods to determine if a type is a function pointer:
Console.WriteLine(fpType.IsFunctionPointer); // True
Console.WriteLine(fpType.IsUnmanagedFunctionPointer); // True
// New methods to obtain the return and parameter types:
Console.WriteLine($"Return type: {fpType.GetFunctionPointerReturnType()}"); // System.Void
foreach (Type parameterType in fpType.GetFunctionPointerParameterTypes())
{
Console.WriteLine($"Parameter type: {parameterType}"); // System.Int32&
}
// Access to custom modifiers and calling conventions requires a "modified type":
Type modifiedType = fieldInfo.GetModifiedFieldType();
// A modified type forwards most members to its underlying type which can be obtained with Type.UnderlyingSystemType:
Type normalType = modifiedType.UnderlyingSystemType;
// New methods to obtain the calling conventions:
foreach (Type callConv in modifiedType.GetFunctionPointerCallingConventions())
{
Console.WriteLine($"Calling convention: {callConv}");
// System.Runtime.CompilerServices.CallConvSuppressGCTransition
// System.Runtime.CompilerServices.CallConvCdecl
}
// New methods to obtain the custom modifiers:
foreach (Type modreq in modifiedType.GetFunctionPointerParameterTypes()[0].GetRequiredCustomModifiers())
{
Console.WriteLine($"Required modifier for first parameter: {modreq }");
// System.Runtime.InteropServices.InAttribute
}
// Sample class that contains a function pointer field:
public unsafe class MyClass
{
public delegate* unmanaged[Cdecl, SuppressGCTransition]<in int, void> _fp;
} Parameterized types including generics, pointers, and arrays such as an array of function pointers (e.g. |
FYI: I think this feature description from @steveharter is a best-practice example: #8134 (comment). It describes the user-facing problem to solve, provides additional contexts (and links) and then ends with a great example. If you are not sure how to write this, Steve's example is a good one. |
System.ComponentModel.DataAnnotations Extensions dotnet/runtime#82311We're introducing extensions to the built-in validation attributes in System.ComponentModel.DataAnnotations:
|
@JeremyLikness, @JonDouglas, et al -- For the DataAnnotations APIs that @eiriktsarpalis called out, it's probably good to note in the blog/release notes/docs that these were inspired by validation scenarios beyond the typical UI data entry validation scenarios that most DataAnnotations validators are geared towards. We've been learning from Options validation scenarios used in cloud-native services, and these new validation attributes are primarily targeting those scenarios. For these cloud-native scenarios, we are expecting to do more work in the DataAnnotations space through the release. |
What is the reason behind to name the counterpart of "AllowedValues" attribute "DeniedValues" instead of "DisallowedValues"? Because it is shorter? DisallowedValues would be the more intuitive candidate to think of (at least for me) |
@CleanCodeX naming follows from allowlists and denylists. |
[Range(0d, 1d, IsLowerBoundExclusive = false, IsUpperBoundExclusive = false)]
public double Sample { get; set; }
Included and Excluded would be clearer terms. "Exclusive" is more commonly used to mean "excludes all others", like "exclusive content" that a media company might generate, or an "exclusive story" that a journalist may write about. In this attribute you intend to mean something like the opposite of that. The current naming is also a double negative sometimes. These both should have been @eiriktsarpalis - Im not going to be able to use this attribute correctly as it currently is without always having to check the docs, and I'm not the only one. I probably won't even bother to check the docs and will just avoid using it because I know these names could be problematic for someone else later. |
@StingyJack - I felt the same way about this but didn't say anything because I felt like I might not be in the majority, but I agree with you 100%. I would even suggest taking it a step further: |
I agree with the two comments above. *Included makes more sense than *Exclusive as its meaning is less open for interpretations. |
In the context of bounds, inclusive and exclusive bounds are standard terms though. |
@demming - maybe they are standard terms if you went to college or at least had some formal education with computer science or enough mathematics. And you know English well enough to know that the "bounds" you are referring to are not the ones from the expression "leaps and bounds", but are referring to a shortened version of the word "boundaries". English is an overly complicated language with lots of odd and inconsistent rules. "IsUpperBoundExclusive" has too many interpretations that could lead to the code being wrong. |
@leecow, package System.ComponentModel.Annotations is marked as deprecated and not maintained in NuGet as of now. But I see there is work on progress on that library going on. Will it be another package? |
@alexaronov The changes are .NET 8 only, we have no plans on releasing a NuGet package update. Because the changes modify APIs of types that are already present in the shared frameworks of earlier versions of .NET, it would be challenging to make these available in a package for older targets. |
@eiriktsarpalis - I see the names of these have changed to In addition to that, both the new and the older names qualify as a negative name, which does not follow long standing convention for booleans. The new names actually go farther away from those conventions than the previous choices due to the placement of the "be" word.
|
I definitely agree with @StingyJack 's comments. |
I have no idea what MinimumIsExclusive/MaximumIsExclusive means. It is highly counter intuitive to me. |
The naming was changed intentionally, rationale can be found here, I would recommend making a case in that issue. |
Thanks for the insight on moving |
What's new in .NET 8 Preview 2
This issue is for teams to highlight work for the community that will release in .NET 8 Preview 2
To add content, use a new conversation entry. The entry should include the team name and feature title as the first line shown in the template below.
Required
Optional
Below are three additional items to consider. These will help the .NET 8 blog team and the community throughout the release.
Index of .NET 8 releases
Preview 1: #8133
Preview 2: #8134
Preview 3: #8135
Preview 4: #8234
Preview 5: https://github.com/dotnet/core/issues
Preview 6: https://github.com/dotnet/core/issues
Preview 7: https://github.com/dotnet/core/issues
RC 1: https://github.com/dotnet/core/issues
RC 2: https://github.com/dotnet/core/issues
The text was updated successfully, but these errors were encountered: