Api should match Linq (Single, First => SingleOption, FirstOption)

[Baccanno]

In this issue you seem to have introduced an option type for some of the linq functions, https://github.com/NetFabric/NetFabric.Hyperlinq/issues/133

However Linq original First and Hyperlinq first now have a different signature. Wouldn't it feel better to specify a new signature such as FirstOpt, FirstOption ? Actually this is what I've done for my own set of Linq extension methods.

It also prevents Hyperlinq to be a drag&drop solution as it will cause regression.

[aalmada]

Hi @Baccanno

Thank you for your feedback.

Hyperlinq is not drag&drop in several cases. IEnumerable<> collections have to be converted to IValueEnumerable<> and IReadOnlyCollection<,> collections have to be converted to IValueReadOnlyCollection<,>. The operation AsValueEnumerable() has to be used for that. It's not required for arrays, Span<>, Memory<>, collections in System.Collections.Generic and in System.Collections.Immutable, because I have extensions for those.

My initial plan was to reproduce the LINQ API as much as possible. I since then changed my mind. I want to create a modern version of LINQ.

I did support First, Single, ElementAt, FirstOrDefault, SingleOrDefault and ElementAtOrDefault. The reason I longer do is that I have to implement them for arrays, Span, ReadOnlySpan, Memory, ReadOnlyMemory, IValueEnumerable, IValueReadOnlyCollection, IReadOnlyList, and IAsyncValueEnumerable. Plus, I have to have unit tests for all of these. I already have more than 7K unit test scenarios.

In #133 I explain all the alternatives I considered. I ended up choosing to return Option.

In this project, I already use source generators. I may consider your naming proposal and use generators to generate the extensions required to support the old behaviors.

[Baccanno]

Thanks for you thorough answer. I indeed believe you should stick with LINQ original naming when signature & behaviour are the same. If behaviour or signature changes then I would set a new name. I feel it's the best practice in what you're trying to create to avoid any headache to developers adopting your solution.

Not being drag & drop is not an issue in itself. Just misleading naming :)

I'm envisioning to try Hyperlinq out in the optimization process of Unity games where heap allocation is an issue.