Andrei Ivascu

@Kralizek indeed, I event named the attribute [AutoTestCaseSourceAttribute](https://github.com/AutoFixture/AutoFixture/pull/1257/files#diff-62d3ab06f353589fdbfe891e7c7003aae784a8bc1ee3e0e82ace7569376146e2R18), so it would be consistent with the NUnit naming. However this proved to not be a good decision in terms of respecting...

@Kralizek if I read the situation correctly, the request has not been rejected, and there is even a PR that fixes it. I had a brief look at the PR...

I've published a feature preview package `5.0.0-dataattributes0001` that fixes this issue. If anyone wishes to help please test the package, and provide feedback. I'll leave it listed until it will...

@jcouturest, thank you for providing feedback. If there's any bugs or performance issues, please let me know. I'd love to just move the fix to v4, but I can't, since...

Hi @putnap, Thank you for raising this issue. What I think the issue is, it's that records create classes that do not properly encapsulate data, when looked at from the...

About the `init` setters you're kinda correct. It does generate the equivalent IL for `init` for positional records, however the difference between a public setter and `init` is an attribute...

Hello @C0DK , Thank you for submitting the PR. Indeed there are some typos in the codebase, that have crept in over time. I'll try to have a look at...

@Romfos2 thank you for the PR. I'm honestly not sure if I should add the support for immutable collections, into the base package of AutoFixture. While I can motivate the...

@Kralizek I agree, there should be a separate kind of packages that add support for common features, that cannot be supported by the official AutoFixture libraries. The "Extras" prefix, is...

@Kralizek yes for Extras there would be a separate repo in the AF organization. I was talking about a separate org in the context of the abandoned AutoFixture.Community.* packages. However...