Suggestion to add SafeStart and SafeEnd extension methods to Interval

Currently, we have usages of the Interval struct involving missing Start/End. The code eventually consolidates the presence/absence of these Instant values into separate fields. However, boilerplate checks have to be added before accessing Interval.Start or Interval.End because of the potential InvalidOperationException.

We have thus implemented convenience methods for these scenarios:

public static T SafeStart<T>(
    this Interval interval,
    Func<Instant, T> startInstantSelector,
    T replace = default) => interval.HasStart
    ? startInstantSelector(interval.Start)
    : replace;

public static T SafeEnd<T>(
    this Interval interval,
    Func<Instant, T> endInstantSelector,
    T replace = default) => interval.HasEnd
    ? endInstantSelector(interval.End)
    : end;

I suspect this is a very common use case and these methods are generic enough to be included in the NodaTime library itself.

[jskeet]

Right. Note that developers would still need to remember to use StartOrNull or SafeStart or whatever we call it - I wouldn’t be changing the existing properties (as that would be a breaking change).

[malcolmr]

-0.5 to calling this SafeStart, fwiw; it’s not really any more or less safe than the existing methods. StartOrNull seems reasonable.

I do wonder how much a method like this would end up being used, and whether it’s worth expanding the API to do so (and writing private extension methods to add those two methods are pretty straightforward).