Skip to content
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

Make Field Initialization Opt-In #145

Merged
merged 3 commits into from
Feb 15, 2020

Conversation

BrunoJuchli
Copy link
Contributor

@BrunoJuchli BrunoJuchli commented Feb 13, 2020

Description

This makes field/property initialization opt-in instead of opt-out.

It is a breaking change, as it replaces the DoNotPreserveInitializers config attribute with one named PreserveInitializers. It also changes the default behavior, thus breaking, again.

The solution

As this is a recently introduced feature and EmptyConstructor.Fody has a long history I assume it's not covering a very common use case. Therefore I'd say it's entirely fine to be opt-in instead of opt-out.
Given the current implementation is buggy, in a breaking way makes it very sensible to be opt-in instead of opt-out.
Furthermore, I suppose the author of the feature, @NorekZ, does not (currently) require the bug to be fixed, thus there is no immediate pressure to fix it and it may well take quite some time to have it fixed. This speaks for making it opt-in, at least until it's stable.
A perfect implementation of the feature could be quite complicated, anyway.
Furthermore I deem it an advanced feature because it's a bit difficult to understand what exactly it does. This speaks for making it opt-in forever (or until we know better).

To sum it up: make it opt-in and leave it like that.


I've also considered making this a less-breaking change by only changing the default value of DoNotPreserveInitializers, but not the name.
Here's my reasoning not to:
All existing users only (had to) introduced the flag in case it wasn't the intended behavior. All of them now have to ensure that all their FodyWeavers.xml have the correct config. The reduced burden of maintaining this (when adding new projects etc.) should outweigh the negative effect of having to remove the attribute.
All users who haven't updated yet might be better off by changing the default behavior and won't be affected by the name change.
Thus, only the users who prefer the feature to be on remain as "victims". Those won't be many, as the feature has only been introduced very recently.

@SimonCropp do you think that's a fair evaluation?

Todos

@SimonCropp SimonCropp added the Bug label Feb 15, 2020
@SimonCropp SimonCropp added this to the 3.0.0 milestone Feb 15, 2020
@SimonCropp
Copy link
Member

@BrunoJuchli thanks for this. i think it is reasonable

@SimonCropp SimonCropp merged commit 3f87bad into Fody:master Feb 15, 2020
@SimonCropp
Copy link
Member

This is now deployed. NuGet may take some time to make it available for download.

@BrunoJuchli
Copy link
Contributor Author

@SimonCropp
Thanks a lot.

@BrunoJuchli BrunoJuchli deleted the FieldInitializationOptIn branch February 17, 2020 06:51
NorekZ pushed a commit to NorekZ/EmptyConstructor that referenced this pull request Jul 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

New Feature "Field Initialization" in 2.1.1 Results in System.InvalidProgramException
2 participants