Summary
CodeSmallifier strips redundant modifiers from declarations inside #region mdk preserve, the same as anywhere else:
So a private readonly List<int> _x; inside a preserve region can come out as List<int> _x;.
This is not a behavior bug
So nothing a user's script does changes, and readability of the region's logic is unaffected.
The actual question
The original intent of preserve was scoped: don't rename identifiers, don't compact whitespace (protect readability and referential stability). The modifier-stripping transforms were added later and are a different category of change (removing a redundant token), not the rename/whitespace/layout compaction that preserve was built to stop. Note that the transforms which do honor preserve today (SymbolRenamer, WhitespaceCompactor, and CodeSmallifier's own CompactFieldDeclarations) all fall inside that original scope; modifier-stripping is the one that does not.
So this isn't clearly a defect - it's a question of what we want preserve to mean going forward:
- (A) Scoped (matches original intent): preserve guarantees names + formatting, nothing more. Leave the code as-is, but consider a one-line docs clarification so the word doesn't over-promise byte-identical output.
- (B) Literal/textual: preserve means "this region comes out exactly as written." Then gate the modifier-stripping (and the existing
private-stripping) on ShouldBePreserved() in CodeSmallifier, consistent with the layout transforms.
Notes
Summary
CodeSmallifierstrips redundant modifiers from declarations inside#region mdk preserve, the same as anywhere else:privateis removed from members with no other accessibility modifier;readonlyandprivatemodifiers during minification (#132) #155)readonlyis removed from reference-type fields.So a
private readonly List<int> _x;inside a preserve region can come out asList<int> _x;.This is not a behavior bug
privateis the default accessibility, so removing it changes nothing.readonlyis only stripped for reference types, where it has no runtime effect (the defensive-copy behavior that matters only applies to value types, and those are deliberately left alone - see feat(pack): strip redundantreadonlyandprivatemodifiers during minification (#132) #155).So nothing a user's script does changes, and readability of the region's logic is unaffected.
The actual question
The original intent of
preservewas scoped: don't rename identifiers, don't compact whitespace (protect readability and referential stability). The modifier-stripping transforms were added later and are a different category of change (removing a redundant token), not the rename/whitespace/layout compaction that preserve was built to stop. Note that the transforms which do honor preserve today (SymbolRenamer, WhitespaceCompactor, and CodeSmallifier's ownCompactFieldDeclarations) all fall inside that original scope; modifier-stripping is the one that does not.So this isn't clearly a defect - it's a question of what we want
preserveto mean going forward:private-stripping) onShouldBePreserved()inCodeSmallifier, consistent with the layout transforms.Notes
private-stripping already ignored preserve before feat(pack): strip redundantreadonlyandprivatemodifiers during minification (#132) #155; feat(pack): strip redundantreadonlyandprivatemodifiers during minification (#132) #155 only extends it (behavior-safely) to reference-typereadonly.Source/Mdk.CommandLine/IngameScript/Pack/DefaultProcessors/CodeSmallifier.cs(theVisitFieldDeclaration/StripPrivatepaths do not checkShouldBePreserved(), unlikeIsSimpleField).