LanguageExt.HashSet<A> clashes with System.Collections.Generic.HashSet<T>

[ThomasBarnekow]

Let me first thank you for your awesome library, which I wanted to start using just now. And I thought it would be a good idea to use the latest beta of v5. However, unfortunately LanguageExt.HashSet<A> clashes with System.Collections.Generic.HashSet<T>, which I am using in my codebase.

The somewhat ironic part is that my very first use case would be the Fin<A> monad because I would like to replace the Result pattern that I am using right now. You explained that you did not call it Result<A> because you wanted to avoid clashes with common type names ...

[louthy]

The difference between Fin and HashSet is that HashSet is part of four types that are related:

• HashMap and Map
• HashSet and Set

Calling HashSet something else to avoid the name clash would lead to inconsistent naming across the library, so it's a special case.

To solve it:

1. Add two global-using aliases:

global using G = System.Collections.Generic;
global using L = LanguageExt;

2. Whenever you need a HashSet (and you have both namespaces included), just prefix with L. or G.:

var xs = new G.HashSet<int>();

Another approach -- the one I take -- is to never use the System collection types as they're all mutable types and against the principles of pure functional programming. The only type I ever use (from System), in my own projects, is IEnumerable<A> and that's usually just so I can convert it to an Iterable<A>.

If you take this more fundamentalist approach then you can disable ImplicitUsings in your csproj and create a global-usings file that brings everything in:

global using System;
global using LanguageExt;
global using LanguageExt.Traits;
global using LanguageExt.Effects;
global using LanguageExt.Common;
global using static LanguageExt.Prelude;
global using G = System.Collections.Generic;
global using L = LanguageExt;

This stops the System.Collections.Generic namespace being implicitly included in your project and prefers the lang-ext collections. Obviously, I realise this isn't for everyone, but really it's a much better experience than using the built-in collections IMHO.

[ThomasBarnekow]

Thank you very much for the very quick response!

I'll look into that approach. However, depending on the codebase, this sounds like it might require lots of changes.

I guess there's no option to have those collections in a separate namespace, right? With a separate namespace, it would be possible to take a step-by-step approach.