Should the implicit Entity[] to Entity conversion go too?

[Rafael-SOWNet]

#853 removes the implicit conversion from List<Entity> to Entity, because it made three params Entity[] overloads impossible to call with a list. The sibling conversion from Entity[] is kept:

public static implicit operator Entity(Entity[] elements) => new FiniteSet(elements);

Keeping it was deliberate and, on its own terms, correct: an array binds to the params overload in its normal form by an identity conversion, which beats the alternatives outright, so it never produced the ambiguity that the List one did.

But it leaves an asymmetry:

Entity a = new Entity[] { 1, 2, 3 };            // a set
Entity b = new List<Entity> { 1, 2, 3 };        // after #853, does not compile
Entity c = new[] { 1, 2, 3 }.ToSet();           // the explicit form, always worked

Two questions worth settling while 2.0 is still in preview, because removing a public conversion afterwards is a 3.0 change:

1. Should the Entity[] conversion go too? An implicit conversion from a collection to a scalar-ish type is the kind of thing that produces surprising overload resolution — this issue exists because its twin did exactly that. .ToSet() and new FiniteSet(...) cover the need explicitly, and MathS.Sets exists.
2. If it stays, is the asymmetry acceptable? It is defensible on the mechanics, but "array converts, list does not" is hard to explain to a caller who has not read the overload-resolution rules.

No behaviour is wrong either way — this is a surface-design decision with a deadline, which is the only reason it is worth an issue rather than a comment. Marking Opinions wanted.

[Happypig375]

Note that converting an array to a set is inherently information-losing because it removes order and duplicate elements. This shouldn't even be a conversion at all; explicit set construction is used for basically all the set types out there.

[Rafael-SOWNet]

You're right, and the reasoning I used to keep it was the wrong test. I kept the Entity[] conversion because it never produced the CS0121 ambiguity its List<Entity> sibling did — which is true, and says nothing about whether it should exist. What a conversion loses is the question, and an array has an order and can repeat where a set has neither.

Both are gone in #866.

Measured before touching anything, since removing a public conversion is only cheap if nothing leans on it: it broke exactly one place in the repository — the test from #853 that pinned the behaviour. Nothing in the library, no other test, no sample, no wrapper. 6084 C# and 130 F# tests pass with it removed.

That test now asserts the opposite and still pays for itself the same way: the file compiling is what says the conversion has not come back.