Put .Core on a diet

[jaider]

The ".Core" project is full of NuGet dependencies and I wonder if we can remove them or make it a separate light version, with Option, and other essential Functional object, without any dependency.

    <PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="7.0.0" />
    <PackageReference Include="System.Reflection.Emit" Version="4.7.0" />
    <PackageReference Include="System.Threading.Tasks.Extensions" Version="[4.5.4,)" />
    <PackageReference Include="System.ValueTuple" Version="[4.5.0,)" />
    <PackageReference Include="Microsoft.CSharp" Version="[4.7.0,)" />
    <PackageReference Include="System.Memory" Version="4.5.5" />
    <PackageReference Include="System.Reflection.Emit.Lightweight" Version="4.7.0" />
    <PackageReference Include="System.Diagnostics.Contracts" Version="[4.3.0,)" />
    <PackageReference Include="System.Linq" Version="[4.3.0,)" />
    <PackageReference Include="System.Linq.Queryable" Version="[4.3.0,)" />

[louthy]

or make it a separate light version, with Option, and other essential Functional object, without any dependency.

The short answer is no, this will never happen.

The longer answer: The purpose of this library is to be a BCL of FP, not an Option library, or other pieces of an FP ecosystem. An Option library on its own is next to useless, or has less value at least, because what matters is how it integrates with everything else. For example, Option has ToSeq(), ToArr(), ToList(), ToTransducer(), ToEff(), ToFin(), ToEither() - allowing natural transformations to other types in language-ext. It has implicit conversions from Fail and Pure - allowing natural transformations from other types in language-ext. And it implements: Functor, Applicative, Monad, Traversable, and Alternative - allowing for common functionality like Map, Bind, Pure, Action, Fold, Empty, and Or. Other types have methods like: HeadOrNone(), Find(), etc. that all return Option. Showing an interrelated dependencies between the types. And that's just the simplest type.

Of course, it would be possible to use combinations of extension methods and other techniques to avoid this - but I don't want to, because I see the power of this library being its 'FP in a box' solution for C#. And whilst there's probably an argument for moving some, non-essential, types out of Core - doing so wouldn't make a difference to the dependencies.

Most of those dependencies you listed are used in the implementation of Option anyway! (well, the pairing of Option and OptionAsync). So even if there were some 'lightweight' libraries with all of the features of language-ext spread out, they'd almost certainly have similar dependency lists.

However, the reason that nearly all of those libraries are referenced is because language-ext is a .NET Standard 2.0 library; .NET Standard has a ton of functionality missing that's in .NET Core and/or .NET Framework. These dependencies patch that missing functionality.

The next major release (v5) is jumping straight to .NET 8.0 and is dropping .NET Standard and .NET Framework support. It changes the list of PackageReference to this:

  <ItemGroup>
  </ItemGroup>

Which is what you desire. But, to be clear, the library still depends on the same types it did before, but now they're in the framework and not separate nuget libraries. So, the situation is no different.