Skip to content

Frequently Asked Questions

Jump to bottom
Paul Louth edited this page Oct 20, 2024 · 26 revisions

Where is Result?

Result was removed from v5 of language-ext because there was constant confusion about its role. Result was originally intended simply as an intermediate type for the Try* lambda-based types and not for public consumption. Unfortunately most people didn't read the documentation and used it thinking it had the same status as Either, Option, etc.

The options were to either keep the type and develop it fully or remove it completely.

The reasons for removal are:

  • I don't like naming commonly used types in a way that is likely to clash with other common libraries (which is why Result was originally parked in another namespace).
    • Result is such a common name that name clashes are likely
  • Another type already does what everybody wants Result to do. It's called Fin<A> and was named based on the French for 'end', 'finished', 'final', ... i.e. Result.
    • This is name that is unlikely to clash and is happily slightly less typing.

Where is OptionAysnc, EitherAsync, and TryAsync?

Why doesn't LanguageExt.CodeGen work?

Officially, it is now deprecated and unsupported. There are future plans to add a new source-generators based project, but that doesn't exist yet.

The library that CodeGen was based on has now been deprecated (since Source Generators became an official MS feature). That makes it next to impossible for me to continue supporting it.

It's probably possible to get it working, but you'll need to install .NET SDK version 2.1.818.

The new traits for Functor, Applicative, Monad, etc. are meant to help in the implementation of functional-types in the way that could only be done with code-gen in the past. So, the advice is to use the new traits system. Paul Louth's Higher Kinds in C# series can help guide you.

Why are you using camelCase names?

"Microsoft says 'no'" is something that the C# community should get over. Microsoft consistently make mistakes, just look at how many failed web-frameworks we've had over the years! They shouldn't be seen as the arbiter of how code should be written.

Of course there are also community norms for writing C# code and using camelCase isn't a norm. So why have I done it?

Primarily, it's because camelCase names look better in LINQ expressions. And because this library is all about pure-functional programming, we expect to use LINQ, pretty much all of the time. Take a look at the CardGame sample to get an idea of what I am talking about. When your entire application is LINQ then the camelCase names come into their own and the code starts to look more like an ML language, like F# or Haskell.

So, it's entirely opinionated, and it may sting, but this library isn't about pandering to norms. It's here to rip up the rule book and create a sub-community within the wider C# community that want to do it differently.

Clone this wiki locally