Implicit null behavior

[Jack-Edwards]

Re: #15

An example for discussion:

public record Order
{
    public int Id { get; set; }
    public int InvoiceId { get; set; }
    public Invoice? Invoice { get; set; }
}

public async Task<Maybe<Invoice?>> GetInvoiceForOrderAsync(int orderId)
{
    var result = await _dbContext.Orders
        .Where(x => x.Id == orderId)
        .Select(x => new { x.Invoice })
        .FirstOrDefaultAsync();
        
    if (result is null)
    {
        return Maybe<Invoice?>.None;
    }

    return result.Invoice;
}

Suppose a client wants to view the invoice for a recently placed order. It takes a while for invoices to be created, so the invoice may not exist. This service method tries to abstract this by supporting the following scenarios:

1. The order does not exist. Expect None.
2. The order does exist, but the invoice does not exist. Expect Some with a null value.
3. The order and invoice both exist. Expect Some with an instantiated value.

The problem is, EasyMonads does not currently work this way. The constructor for Maybe returns an instance in the None state if the provided value == null. Scenario 2 (above) is broken.

[Jack-Edwards]

Thinking about adding where TValue : notnull to the type definitions. Seems that projects can still build, but the usage should get flagged.

[jltrem]

Does this mean the following will change?

Instead of throwing runtime exceptions or asking you to use methods with a different naming convention, this library will try to let you do what you want and continue running.

Throwing an exception when null is used for construction seems correct to me.

Could also make a similar purpose-built type MaybeNull that works similarly to the current functionality.

[jltrem]

Also consider a ToMaybe extension for Nullable instead of Maybe<T>.FromNullable

[Jack-Edwards]

Does this mean the following will change?

I don't believe so, though I have not tested it yet. My current impression is this will just be a compilation-time warning.

[jltrem]

My suggestion is to enforce it with a guard/exception in the ctor.

"Null means None" could have first-class support in the library by adding a MaybeNull type. It would be monadic Nullable<T> with no possibility of nullref.

If there are use cases best solved with "Some or None or Null" (Maybe or Null) then another type for this could be added too.

[jltrem]

FWIW - language-ext is undergoing a major refactoring. Here is the discussion around Option/OptionUnsafe and nullable types: louthy/language-ext#1291. I'm not suggesting you/we follow any particular decision made in that library. But he has thought longer and deeper about this than I have 😸 so there may be helpful info.