Activity

1. leecow

   added

   documentation

   on Jan 24, 2023
2. steveharter commented on Feb 24, 2023

   

   steveharter

   on Feb 24, 2023

   More actions

   System.Reflection: introspection support for function pointers

   This feature adds the capability to obtain function pointer metadata including parameter types, the return type and the calling conventions. Previously, the IntPtr type was used for a function pointer type such as with typeof(delegate*<void>()) or when obtaining a function pointer type through reflection such as with FieldInfo.FieldType.

   A function pointer instance, which is a physical address to a function, continues to be represented as an IntPtr; only the reflection type was changed with this feature.

   This new functionality is currently implemented in the CoreCLR runtime and in MetadataLoadContext. Support for the Mono and NativeAOT runtimes are expected later.

   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. delegate*<void>[]) are supported. Thus, the Type.ElementType property and the Type.GetGenericArguments() method can be used to obtain further types which ultimately may be a function pointer. In addition, a function pointer parameter type is allowed to be another function pointer type.

   👍React with 👍5Reacted by Max Katz, Rich Lander, Jiachen Jiang, Ralf and GrayAlex715

   ❤️React with ❤️2Reacted by Yuuki Wesp and Benjamin Moir
3. richlander commented on Mar 6, 2023

   

   richlander

   on Mar 6, 2023

   Member

   More actions

   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.

   ❤️React with ❤️2Reacted by Eric StJohn and Jeff Handley
4. eiriktsarpalis commented on Mar 7, 2023

   

   eiriktsarpalis

   on Mar 7, 2023

   Member

   More actions

   System.ComponentModel.DataAnnotations Extensions dotnet/runtime#82311

   We're introducing extensions to the built-in validation attributes in System.ComponentModel.DataAnnotations:

   RequiredAttribute.DisallowAllDefaultValues

   The RequiredAttribute now allows validating that structs do not equal their default values. For example:

   [Required(DisallowAllDefaultValues = true)]
   public Guid MyGuidValue { get; set; }

   will fail validation if its value equals Guid.Empty.

   RangeAttribute exclusive bounds

   Users can now specify exclusive bounds in their range validation:

   [Range(0d, 1d, IsLowerBoundExclusive = false, IsUpperBoundExclusive = false)]
   public double Sample { get; set; }

   This accepts any values in the open $(0, 1)$ interval but rejects the boundary values 0 and 1 themselves.

   LengthAttribute

   The LengthAttribute can now be used to set both lower and upper bounds for strings or collections:

   [Length(10, 20)] // Require at least 10 elements and at most 20 elements.
   public ICollection<int> Values { get; set; }

   AllowedValuesAttribute and DeniedValuesAttribute

   These attributes can be used to specify allow lists and deny lists for validating a property:

   [AllowedValues("apple", "banana", "mango")]
   public string Fruit { get; set; }
   
   [DeniedValues("pineapple", "anchovy", "broccoli")]
   public string PizzaTopping { get; set; }

   Base64StringAttribute

   As the name suggests, this attribute validates that a given string is a valid Base64 representation.

   👍React with 👍12Reacted by Varorbc, Weihan Li, Alerinos, Ssewannonda Keith Edwin, André Pedroso, Martin Žid, Odai Wattad, Yuri, YohanS, N0D4N and 2 more
5. jeffhandley commented on Mar 8, 2023

   

   jeffhandley

   on Mar 8, 2023

   Member

   More actions

   @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. Base64StringAttribute is a clear example of a piece of data that would come from configuration or another system, and not from user's data entry.

   For these cloud-native scenarios, we are expecting to do more work in the DataAnnotations space through the release.

   👍React with 👍3Reacted by Ssewannonda Keith Edwin, well.james and Adipa Wijayathilaka
6. CleanCodeX commented on Mar 14, 2023

   

   CleanCodeX

   on Mar 14, 2023

   Last edited by CleanCodeX

   More actions

   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)
7. eiriktsarpalis commented on Mar 14, 2023

   

   eiriktsarpalis

   on Mar 14, 2023

   Member

   More actions

   @CleanCodeX naming follows from allowlists and denylists.

   👍React with 👍1Reacted by Rich Lander
8. JonDouglas commented on Mar 24, 2023

   

   JonDouglas

   on Mar 24, 2023

   Collaborator

   More actions

   Released: https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-preview-2/
9. JonDouglas

   closed this as completedon Mar 24, 2023
10. StingyJack commented on Mar 25, 2023

    

    StingyJack

    on Mar 25, 2023

    Last edited by StingyJack

    More actions

     [Range(0d, 1d, IsLowerBoundExclusive = false, IsUpperBoundExclusive = false)]
    public double Sample { get; set; }

    This accepts any values in the open
    interval but rejects the boundary values 0 and 1 themselves.

    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 Is*BoundIncluded

    @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.
11. TonyValenti commented on Mar 25, 2023

    

    TonyValenti

    on Mar 25, 2023

    More actions

    @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:
    Includes*Bound

    👍React with 👍1Reacted by Daniel Svensson
12. CleanCodeX commented on Mar 25, 2023

    

    CleanCodeX

    on Mar 25, 2023

    More actions

    I agree with the two comments above. *Included makes more sense than *Exclusive as its meaning is less open for interpretations.
    Because it is in preview, the naming still could be changed. (But will it be changed?)
13. demming commented on Apr 16, 2023

    

    demming

    on Apr 16, 2023

    More actions

    In the context of bounds, inclusive and exclusive bounds are standard terms though.
14. StingyJack commented on Apr 18, 2023

    

    StingyJack

    on Apr 18, 2023

    More actions

    @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.
15. leecow

    changed the title [-]What's new in .NET 8 Preview 2 [WIP][/-] [+]What's new in .NET 8 Preview 2[/+] on Apr 20, 2023
16. alexaronov commented on May 6, 2023

    

    alexaronov

    on May 6, 2023

    More actions

    @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?
17. eiriktsarpalis commented on May 6, 2023

    

    eiriktsarpalis

    on May 6, 2023

    Member

    More actions

    @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.

    👍React with 👍1Reacted by Alexander Aronov
18. StingyJack commented on May 7, 2023

    

    StingyJack

    on May 7, 2023

    More actions

    @eiriktsarpalis - I see the names of these have changed to MinimumIsExclusive and MaximumIsExclusive and these solve part of the problem with the naming, but they leave the part that will create the most bugs and that is the word "Exclusive". This is the bigger of the two problematic parts because of how it conflicts with idiomatic use of the word. I am aware that c# is not English but our programs that do use English words should be borrowing ones with unambiguous meanings.

    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.

    IsMinimumIncluded and IsMaximumIncluded would be properly aligned with those conventions (and may even be shortened to IsMaxIncluded and IsMinIncluded and still be permissible) and would be much clearer for the entire user base.
19. TonyValenti commented on May 7, 2023

    

    TonyValenti

    on May 7, 2023

    More actions

    I definitely agree with @StingyJack 's comments.

    👍React with 👍1Reacted by Clean Coder
20. CleanCodeX commented on May 7, 2023

    

    CleanCodeX

    on May 7, 2023

    More actions

    I have no idea what MinimumIsExclusive/MaximumIsExclusive means. It is highly counter intuitive to me.
    I also agree with @StingyJack's comments, but I would prefer MinimumIsIncluded instead of IsMinimumIncluded , which may not align perfectly with naming convention but is the most understandable naming to me (and probably to many more people)
21. eiriktsarpalis commented on May 8, 2023

    

    eiriktsarpalis

    on May 8, 2023

    Last edited by eiriktsarpalis

    Member

    More actions

    The naming was changed intentionally, rationale can be found here, I would recommend making a case in that issue.
22. TonyValenti commented on May 8, 2023

    

    TonyValenti

    on May 8, 2023

    More actions

    Thanks for the insight on moving Is.
    I still think that the properties should be renamed to Inclusive so as to not have a double negative
    Exclusive = False is confusing.
    Inclusive = True not so much.

    👍React with 👍1Reacted by Clean Coder