Why don't we have a FirstOrNone method?

[MrYossu]

Sorry if this is a stupid question, but you don't get anywhere if you don't ask!

As a slowly reforming OO programmer, I'm trying not to write code like this...

Customer jim = await ctx.Customers.FirstOrDefault(c => c.FirstName = "Jim");
if (jim != null) {
  // Do something with jim
} else {
  // Do whatever we do if Jim has gone on holiday
}

...but rather write code like this...

GetUser("jim")
  .Match(u => Console.WriteLine($"Found {u.FirstName} {u.Surname}"),
         () => Console.WriteLine("Nope"));

Option<AspNetUsers> GetUser(string firstName) =>
  AspNetUsers.FirstOrDefault(u => u.FirstName == firstName);

It seems it would be useful to have a FirstOrNone method...

  public static Option<T> FirstOrNone<T>(this IEnumerable<T> coll, Predicate<T> f) {
    return coll.FirstOrDefault(t => f(t));

...as this would enable us to achieve the same without needing our own GetUser method...

customers
  .FirstOrNone(u => u.FirstName == "Jim")
  .Match(u => Console.WriteLine($"Found {u.FirstName} {u.Surname}"), () => Console.WriteLine("Nope"));

Does LanguageExt have anything like this? If not, is there a good reason why not?

[tanxeel90]

There is a HeadOrNone extension for IEnumerable:

language-ext/LanguageExt.Core/DataTypes/List/Lst.Extensions.cs

Line 109 in 652f38f

public static Option<T> HeadOrNone<T>(this IEnumerable<T> list) =>

For your case, it will be something like:

     customers.Filter(u => u.FirstName == "Jim").HeadOrNone()

[MrYossu]

@tanxeel90 Thanks for the reply, I didn't know about HeadOrNone (as with so much of this amazing library!). The shame of HeadOrNone is that it doesn't take a lambda, so you need the extra Filter before.

Thanks all the same, it gives me somewhere else in this code base to investigate!

[MartonBoda]

Isn't "Find" what you're looking for? Returns the first matching element or none. customers.Find(u => u.FirstName == "Jim")

…

On Thu, 14 Oct 2021 at 17:38, tanxeel90 ***@***.***> wrote: There is a HeadOrNone extension for IEnumerable: https://github.com/louthy/language-ext/blob/652f38ff754787bcf069ec79c72593d507903ac9/LanguageExt.Core/DataTypes/List/Lst.Extensions.cs#L109 For your case, it will be something like: customers.Filter(u => u.FirstName == "Jim").HeadOrNone() — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#925 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA57NKMN53565UUOKK2TQUDUG4ITHANCNFSM5GAE2C4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[MrYossu]

@MartonBoda Yes, it's exactly what I was looking for, I just didn't know about it!

Thanks again.

[louthy]

Both @tanxeel90 and @MartonBoda are correct here. Tanzeel's is a direct answer to what was asked, but Marton's answer is probably the easiest to work with.

[MrYossu]

@louthy Thanks for moving this, I'd never noticed the discussions! Guess it's like the whole library, I need to spend a lot more time looking around, as there are plenty of gems I've never seen.

Why would we ever use HeadOrNone when Find does the same thing (does it?), but takes a lambda, allowing us to do what I was asking in one step, rather than having to filter first.

Thanks again.

[louthy]

Why would we ever use HeadOrNone when Find does the same thing (does it?), but takes a lambda, allowing us to do what I was asking in one step, rather than having to filter first.

They're not the same. One filters, one doesn't.

[MrYossu]

Why would we ever use HeadOrNone when Find does the same thing (does it?), but takes a lambda, allowing us to do what I was asking in one step, rather than having to filter first.

They're not the same. One filters, one doesn't.

Sorry, I didn't make myself clear.

The point of my question was meant to be, given that Find does the same Option<T>-returning benefit as HeadOrNone, ie return the first item if there is one, and None if not, but also filters (saving the need to do that beforehand), why would we ever use HeadOrNone?

[StefanBertels]

Hi @MrYossu,

those three functions have different input/output types which means they cannot replace each other at all.

1. Filter will produce output which just contains some of the input values. In many cases you get exactly same type as input type and for immutable data structures you get a copy of the input. Semantically like .Where(...).

2. HeadOrNone will just peek into some some data structure and give you the first item. Unlike Head which will do this in an unsafe way (throwing errors if empty) you will get an Option<T>. Similar to .FirstOrDefault() but avoiding "million dollar problem" NullReferenceException.

3. Find will lookup a (single) value. For dictionary types (maps) there is a variant just taking the key (similar to TryGetValue). For every other iterable container data type (probably everything IEnumerable<T> including dictionaries as IEnumerable<(TKey, TValue)> you can use this with a predicate function. The latter variant is semantically identical to .Filter(predicate).HeadOrNone() but as Filter might build a expensive copy of your input (worst case) or at least will produce some boxing or helper data structures you should not use this if you don't need it.

Your probably will find more methods that can be replaced by other methods (or their combination) and some even have "trivial" implementations in the library itself. If you're working with this library for some time you probably will see how useful those single methods are -- last but not least improving readability.