I'd like to know why it is that the generic Customize overload returns void and seems to mutate the fixture when the non-generic overload, which takes an instance of a ICustomization, returns an IFixture?
// you cannot set this var, customize returns void
var configuredFixture = fixture.Customize<whatever>(x => x.OmitAutoProperties());
// this is valid
var configuredFixture = fixture.Customize(new AutoMoqCustomization());
I ask because I had thought to inline a customization using the fluent style doing something like below, which is of course not valid.
var localFixture = fixture
.Customize(new AutoMoqCustomization())
.Customize<whatever>(x => x.OmitAutoProperties()));
The overall answer is: because I made mistakes
These two methods are, unfortunately, not particularly related, and you should really think of them as being different, and having two different names, like Foo<T>, and Bar.
When I wrote those functions, I couldn't think of a better name; hence the unfortunate, but mostly incidental, similarity.
IIRC, I created those two methods at different phases in the development of AutoFixture. AFAIR, Customize<T> came first.
After some use of AutoFixture, I realised that it'd be nice with a formal 'module' or 'package' system for AutoFixture, so I added ICustomization, and the Customize method to go with it.
It was my original intent that one could chain together calls to Customize, so I added the Fluent Interface (i.e. returned the IFixture instance) to enable that. The intent was to make it a convenience, but in hindsight, I consider it a mistake. The method does mutate the input argument, so that design violates Command Query Separation.
In my defense, though, Fluent Interfaces were all the rage back then...
One really ought to add an issue to the AutoFixture repository to remove the return value from Customize...