Conflict between LangugeExt Extension methods and LINQ Extension methods

[attejan]

Description

Extension methods are not in any namespace thus causing problems in a large project. Instead of Linq - extension methods, the whole project is forced to use extension methods from LanguageExt.

Steps for minimal reproduce

https://github.com/attejan/LanguageExtListExtensionRepro

1. Create a new project
2. Use Zip and Append in a way that is supported in LINQ.

// See https://aka.ms/new-console-template for more information

var foo = new List<Foo>();
var bar = new List<Foo>().Zip(foo).All(c => c.First == c.Second);
var barz = foo.Append(new() { Barz = new Bar[] { } });

internal record Foo
{
    public Bar[] Barz { get; set; }
}

internal record Bar { }

3. Install LangugeExtCore
4. Now Zip and Append signatures are different since the whole project is being forced to use LanguageExt - extension methods.
   

Expected behavior

The extension methods provided by the library should not conflict with the ones provided by LINQ. It should be possible to use both sets of extension methods without any ambiguity.

Actual behavior

List extension methods from LangugeExt are used and they break.

Possible fix

Iclude all extension methods in a namespace.
Theres probably a reason why it was done like this in the first place, but I would be happy to hear some possible solutions to this problem.

Similar issues

#836
#445

Please let me know if you require any further information or if there's any way I can assist in resolving this issue.
Thanks for this library!

[louthy]

Not sure how that once slipped through, but seeing as there are workarounds I will leave this until after I have completed my v5 work, which is more important to me right now and I only have limited time (which also includes not dealing with PRs).

Workaround #1:

Stop using List. Mutable lists are not the functional way. Opt for Seq, the most performant immutable list type going.

using static LanguageExt.Prelude;

var foo = Seq<Foo>();
var bar = Seq<Foo>().Zip(foo).ForAll(c => c.Item1 == c.Item2);
var barz = foo.Add(new() { Barz = new Bar[] { } });

internal record Foo
{
    public Bar[] Barz { get; set; }
}

internal record Bar { }

Workaround #2:

Use the actual tuple variable member-names and explicitly specify the type.

var foo = new List<Foo>();
var bar = new List<Foo>().Zip(foo).All(c => c.Item1 == c.Item2);
var barz = foo.Append(new Foo() { Barz = new Bar[] { } });

internal record Foo
{
    public Bar[] Barz { get; set; }
}

internal record Bar { }

[attejan]

Yes these workarounds would fix the problem. However in a large large project adding LanguageExt will affect all the for example List - extension methods since there's no namespace ?

Lets say I'm creating a new feature to a legacy product and would like to introduce more functional programming approach.
When I install LanguageExt - and intend to use it only in my new feature and possible future ones, the library affects now all of the existing features too, since I cant explicitly import the namespace "LanguageExt" - extension methods.
If this is the case adding LanguageExt - would require a lot of testing for all of the existing features, when I'm only planning to use it in a certain new feature.

Only workarounds I can think of for this would be to create a own wrapper library. I also understand that creating new namespaces would probably be a breaking change for existing projects.