-
Notifications
You must be signed in to change notification settings - Fork 2
Migration to 5.0
Tiger.Types 5.0 is a moderate rethinking of the organization and capabilities of the library. Taking lessons from years of implementation experience across several teams, Tiger.Types has become a larger and more useful API.
The roadmap for releases in the 5.x series is this:
- 5.0: The Apocalyptic Changes Release
- 5.1: The Collecting Extensions Release
- 5.2: The Applicative Revolution Release
- 5.3: The Null-Check Elimination Release
Upcoming features in C# 8 may alter or remove some of these releases.
- The
Errortype has been moved into Tiger.Types without major modification. -
Result<TOk>has been retired in favor ofEither<TLeft, TRight> -
Try<TOk>has grown an error type, and is now spelledTry<TErr, TOk>
Development experience has shown that the relevant applications of Error are not as wide as previously supposed. Teams have taken Tiger.Types into domains which were not foreseen, and for those domains, Either<TLeft, TRight> is more useful. Additionally, the type-signature convenience of Result<TOk> and Try<TOk> was too tempting, and these types were applied in situations when they were not the right fit.
Result<TOk> can be replaced directly with Either<Error, TRight>, and Try<TOk> can be replaced directly with Try<Error, TOk>. No functionality will be lost, and quite a lot will be gained, as pains were taken to make these types bi-mappable, bi-bindable, bi-tappable, and so on. However, the new pattern-matching capabilities of C# may make applying Exception in place of Error significantly more useful, especially for applications resembling AWS Lambda Functions.
The previous design was considered from a viewpoint of convenience in declaration and refactoring. If a method called within a Map method became asynchronous, a developer would not have to change all the outer Map calls. This fell apart in the face of C#'s limited type inference. Developers overwhelmingly would prefer to be able to use method groups in Map, Bind, and the like, and differentiating between the sync and async versions of methods makes this possible in more places. Additionally, the functionality behind the Async variants may change completely when Tiger.Types grows support for applicative abstractions.
Some environments require the use of exceptions. AWS Lambda Functions, for example, can only report errors via thrown exception. Currently, the prevailing pattern is to use Error as the error type and check the state of the Tiger.Types value directly. If error, forcibly unwrap to the error type, convert to an exception, and throw that exception. If not error, forcibly unwrap to the value type, and continue. This is both inconvenient and error-prone, so an escape hatch in the form of the Assert method has been added to all relevant types. This performs all of the actions described in the current pattern, accepting a lambda for transformation to an exception. Additionally, if the error type of the type is Exception (or any subclass), no transformation is required.
Tiger.Types targets both "netstandard1.0" and "netstandard2.0". On frameworks that support "netstandard2.0", Tiger.Types will prefer libraries supplied by the framework over those from NuGet for libraries such as "System.ValueType" and "System.Collections.Immutable".
This one's just housekeeping. In C#, IDictionary<TKey, TValue> does not inherit from IReadOnlyDictionary<TKey, TValue>. Providing TryGetValue for both of them means that some classes such as Dictionary<TKey, TValue> get confused about which overload to call. Additional extension methods for Dictionary<TKey, TValue> and ImmutableDictionary<TKey, TValue> have been provided to reduce the incidence of this.
No one was using them.
This document only attempts to document the breaking or pattern-improving changes to the library. Nearly all of the methods in Tiger.Types have received an improvement, whether in runtime efficiency or in new, convenient overloads.