It might actually be nice to keep the config overloads. Thoughts?

I think we should only expose a single way to configure properties; this new API should be the only API.

I am not exactly sure what is being discussed here. However, I am not overly concerned with the C# API.

I gave the PropertyConfig.defaultConfig zero thought.

We'll need to audit the use of this function, if it's being used as prop |> toGen |> doGenThing |> ofGen, then we'll lose the original configuration.

Indeed. All such calls should be replaced with Property.Generator.map (as I structured/named it in another comment).

How about, it a PR before this one, we change Property from a single case discriminated union to a record with a single field as well as expressing all maps over that field as such? Then I think it would easier to verify where PropertyConfig.defaultConfig should be used.

I think this should be called withDefaultShrinks.

I'm okay with this, the current name withoutShrinks sounds as if no shrinking will occur.

I think a better name that withDefaultShrinks (which is a syntactic name) is withUnlimitedShrinking (which is a semantic name)

Might be nice to just take an int instead of an int<shrinks>

Can you expand on this?

What about making this into a record? How about this?

{ Config: PropertyConfig
  Generator: Gen<Journal * Outcome<'a>> }

I'm okay with this, I think we should also mark the internals as private, and use lower camel case for the names:

// unsure of the validity of this syntax, just typing into the comment editor right now
type Property<'a> =
    private
    {
        config: PropertyConfig
        generator: Gen<Journal * Outcome<'a>>
    }

In any case, we should make 2 accessor functions, and only use them. They can be marked as inline if we have performance concerns.

let inline config (property : Property<'a>) : PropertyConfig =
    property.config

// This already exists as 'toGen'
let inline generator (property : Property<'a>) : PropertyConfig =
    property.generator

Thoughts?

I am ok with removing the public access scope. However, I think the access scope should be internal instead of private.

I think we should follow the F# naming guidelines and use Pascal case for record field names.

The most common operation is mapping, not (just) getting. As such, I think we should create a submodule inside Property like this (@dharmaturtle knows what I mean):

module Config =
  let get p = p.Config
  let set p c = { p with Config = c }
  let map f p = { p with Config = f p.Config }

These two |> should be on separate lines for readability.

I think we can get rid of this, and only expose configuration with Property.with*

This is the same as Property.Config.set (as I strucutured/named it in another comment). I think it is better to keep. Might want to consider renaming to setConfig though.

What would the value be in overriding a user's preferences?

It would be the user calling this function, it would be their preference. For example, @dharmaturtle talks about how he runs PB tests with a time limit during development and with a test limit during integration. I think the minimal amount of duplicated code to achieve this would be constructing the correct PropertyConfig instance in a global location and then referencing it from all the PB tests in order to set it, which (when using C#) would be achieved via this method.

You could also make an extension method of Property that configures them to all be the same and call that on each property you want it to apply to.

public static Property ConfigureSpecifically(this Property property) =>
    property.WithTests(1000).WithoutShrinkLimit().Whatever();

// in a test

var someProperty = // ...
someProperty.ConfigureSpecifically().OverrideLocally().Check();

Good point.

I think I would still keep this myself, but I won't argue further in favor of keeping it.

I think we should only expose a single way to configure properties; this new API should be the only API.