Skip to content

[3.0] Improve handling of nested struct names and affixes#2555

Draft
Exanite wants to merge 25 commits intodotnet:develop/3.0from
Exanite:feature/nested-struct-name-affixes
Draft

[3.0] Improve handling of nested struct names and affixes#2555
Exanite wants to merge 25 commits intodotnet:develop/3.0from
Exanite:feature/nested-struct-name-affixes

Conversation

@Exanite
Copy link
Copy Markdown
Member

@Exanite Exanite commented Mar 24, 2026

Summary of the PR

(WIP)

Nested struct names are an edge case in the name affix system because they have the following format:

NestedStructName = ParentBaseName + ParentSuffix + FieldBaseName + FieldSuffix

Currently, nested struct names are generated by directly combining the full parent type name with the full field name.
This leads to issues where the ParentSuffix is not handled correctly.

For example, PerformanceCounterDescriptionArmName should be PerformanceCounterDescriptionARMName.

Related issues, Discord discussions, or proposals

Original discussion: https://discord.com/channels/521092042781229087/587346162802229298/1460017726813900975

Further Comments

Tasks

  • Improve handling of nested struct names
  • Consider splitting ExtractNestedTyping and TransformHandles into a new set of Extract- mods.
    • This this mainly for maintainability for ExtractNestedTyping, but for TransformHandles it is useful for AddApiProfiles to be executed after all types are extracted, but not yet transformed.
    • Split TransformHandles into TransformHandles and ExtractHandles
    • Also split up ExtractNestedTyping
      • Note: Currently holding off on this since this has performance implications.
  • Address INameTrimmer.Order/Version issue (we don't want magic numbers) and consider removing INameTrimmer entirely.
  • Rename INameTrimmer to INameProcessor and update names where relevant
    • Do a second documentation pass to ensure that all docs and variable names are updated
  • Regenerate all bindings using Windows

Exanite added 19 commits March 25, 2026 10:46
Considering we decided to follow Microsoft's Framework Design Guidelines (acronym threshold of 2) for the bindings and rest of the API, might as well be consistent here.
This lets us handle prefixing and prettification separately, which notably is important if we add prefixes after prettification.
We want to prefix the final name, not the intermediate name in this case.
This no longer makes sense to keep and enabling features by baseline version seems fiddly.
If we need to toggle features for newer versions, we can explicitly add a boolean config option.
@Exanite Exanite force-pushed the feature/nested-struct-name-affixes branch from 2693e05 to adf4eee Compare March 28, 2026 02:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

1 participant