Algebraic Data Types (ADTs, Sealed Classes, Enum with associated values)

[ZakTaccardi]

ADTs are a very important part of any modern programming language.

• Kotlin has sealed classes
• Swift has enums with associated values

Imagine you have a network call that submits login credentials. This call can:

• log the user in
• fail because the user entered incorrect wrong credentials
• fail because the user doesn't have network connectivity
• fail because of an unknown defect in your code or server broke API contract and the call failed

In Kotlin, the return value could be represented as the following sealed class

sealed class LoginResponse {
    data class Success(val authToken) : LoginResponse()
    object InvalidCredentials : LoginResponse()
    object NoNetwork : LoginResponse()
    data class UnexpectedException(val exception: Exception) : LoginResponse()
}

Kotlin's when statement unwraps this beautifully, smart casting LoginResponse.

fun on(loginResponse: LoginResponse) {
    return when (loginResponse) {
        is LoginResponse.Success -> {
            // direct access to auth token available w/o need to cast
            loginResponse.authToken
        }
        is LoginResponse.InvalidCredentials -> {

        }
        is LoginResponse.NoNetwork -> {

        }
        is LoginResponse.Unexpected -> {
            // direct access to exception available w/o need to cast
            loginResponse.exception
        }
    }
}

Sadly, languages like Java and Dart are unable to elegantly express this concept (ADTs). For a best case example, checkout out Retrofit's Response object. It is a single pojo that contains both:

• The success .body()
• The .errorBody()

Both these fields are nullable, but one must be non-null and the other must be null. To know which field can be accessed, you have to check the .isSuccessful() flag.

Now imagine the verbosity if this best case scenario has to scale to 4 or more possible results. A whole new enum class would have to be added to work around it...it's not pretty.

Please add support for ADTs to Dart.

note: As an Android developer, I find that Flutter is an interesting proposition that is currently held back by the language.

[avilladsen]

I also was initially put off by the lack of ADTs in Dart. But while there isn't language-level support, ADTs can be decently represented in Dart. For example, here's how I would translate your Kotlin example into Dart:

abstract class LoginResponse {
  // Not necessary when case classes are public, 
  // but I usually put factories and constants on the base class.
  
  factory LoginResponse.success(authToken) = LoginSuccess;
  static const invalidCredentials = const InvalidLoginCredentials();
  static const noNetwork = const NoNetworkForLogin();
  factory LoginResponse.unexpectedException(Exception exception) = UnexpectedLoginException;
}

class LoginSuccess implements LoginResponse {
  final authToken;
  const LoginSuccess(this.authToken);
}

class InvalidLoginCredentials implements LoginResponse {
  const InvalidLoginCredentials();
}

class NoNetworkForLogin implements LoginResponse {
  const NoNetworkForLogin();
}

class UnexpectedLoginException implements LoginResponse {
  final Exception exception;
  const UnexpectedLoginException(this.exception);
}

And for the when statement:

void on(LoginResponse loginResponse) {
  if (loginResponse is LoginSuccess) {
    // Dart has smart casting too, so you can use authToken w/o a cast
    loginResponse.authToken;
  } else if (loginResponse is InvalidLoginCredentials) {
    
  } else if (loginResponse is NoNetworkForLogin) {
    
  } else if (loginResponse is UnexpectedLoginException) {
    // Dart has smart casting too, so you can use exception w/o a cast
    loginResponse.exception;
  } else {
    // Dart doesn't have sealed classes
    throw new ArgumentError.value(loginResponse, 'loginResponse', 'Unexpected subtype of LoginResponse');
  }
}

Does this satisfy your request for ADTs? I've been using this pattern myself for a while, and at this point I don't think that Dart needs language-level support for ADTs per se (though I wouldn't complain if it was added).

Because Dart does not have sealed classes or a when-like statement, you can have runtime type errors, which is the one thing I'm really not happy with. I'd be in favor of adding those to Dart. However, as has been pointed out elsewhere, those are really a separate, broader issue than ADTs.

[ZakTaccardi]

ADTs can be decently represented in Dart

I'm looking for language level support, unfortunately. A modern programming language should make it easy to represent ADTs.

At least Dart has smart casting

[avilladsen]

Can you be specific about what you're looking for in language-level support that is not currently possible in Dart? Is it the more concise syntax for declaring ADTs? The static checking of when-style statements?

[brianegan]

Hey @avilladsen --

The features I would like (whether it's sealed classes or union types):

1. Exhaustive Checking with automatic casting inside when + is expressions. This provides static analysis to ensure you're handling each and every case. This eliminates the need for some types of tests.
2. Constrained types. Not open for extension outside of the declaration. This makes reading the code a breeze, since you can see "Ok, this type encapsulates exactly these responsibilities".
3. Concise syntax without ==, toString, and hashcode and copy boilerplate, although I think "data classes" are a separate issue. For example, none of your classes include these methods, and they need to be implemented for testing to work more easily.
4. Convenient Domain Modeling: https://skillsmatter.com/skillscasts/4971-domain-driven-design-with-scott-wlaschin

Sure, defining a class with some subclasses will work in combination with is checks, but it's not as safe (lack of exhaustive checking, need to write more tests) and more verbose. I think you can see a great example of modeling state in this fashion here: https://github.com/freeletics/RxRedux#usage

You can see an attempt that some of us in the community have worked on to achieve this: https://github.com/fluttercommunity/dart_sealed_unions

You could also use built_value to generate the ==, toString etc, but that is also difficult to read and requires a build step.

Therefore, we can paper over these issues with libraries, but they're far more cumbersome and much harder to read than workin with sealed + data classes in Kotlin. In fact, I even prefer the Scala version with pattern matching and destructuring: https://docs.scala-lang.org/tour/pattern-matching.html

[pulyaevskiy]

Concise syntax without ==, toString, and hashcode and copy boilerplate, although I think "data classes" are a separate issue.

This is the main source of boilerplate code for me. And this is a lot of boilerplate.

Not sure if ADTs are supposed to address this, but It’s probably number 1 feature in my wishlist.

[lrhn]

Very similar to http://github.com/dart-lang/sdk/issues/31253.

[jarlestabell]

I've been developing in Flutter for two weeks and I've been really blown away by the incredibly well thought of framework and surrounding tooling!
I think Flutter is the biggest progress when it comes to developer productivity for UI programming since Visual Basic 1.0 / Delphi 1.0 et al in the mid nineties.

But I really miss the beautiful sum types of the ML-family (OCAML, F#, ReasonML, Haskell etc).
Please compare the Dart example from @avilladsen :

abstract class LoginResponse {
  factory LoginResponse.success(authToken) = LoginSuccess;
  static const invalidCredentials = const InvalidLoginCredentials();
  static const noNetwork = const NoNetworkForLogin();
  factory LoginResponse.unexpectedException(Exception exception) = UnexpectedLoginException;
}

class LoginSuccess implements LoginResponse {
  final authToken;
  const LoginSuccess(this.authToken);
}

class InvalidLoginCredentials implements LoginResponse {
  const InvalidLoginCredentials();
}

class NoNetworkForLogin implements LoginResponse {
  const NoNetworkForLogin();
}

class UnexpectedLoginException implements LoginResponse {
  final Exception exception;
  const UnexpectedLoginException(this.exception);
}

to how you would write the same in say F#:

type LoginResponse =
  | Success of AuthToken
  | InvalidCredentials
  | NoNetwork
  | UnexpectedException of Exception

(I use the same shorter names as in @ZakTaccardi's original Kotlin example)

You get much better data/domain modelling inside your code when you have tools like this available in the language (@brianegan makes the same argument). It improves readability and quality of the code, not the least because it enables preventing many more illegal states at compile time. And since it is so easy to read and write, you do it right instead of often cheating like you would do in say Dart because you would have to write so much more code to do it "correctly".
Dart is a nice language, and Flutter is a killer. For me, the biggest lack in Flutter is these data modelling capabilities (and pattern matching) of languages of the ML family. (Scala and Kotlin have similar capabilities, but more verbose syntax)
For non-trivial UI I quite often find finite state automata very useful and sum types (and the corresponding pattern matching) is perfect for this.

[richard-uk1]

Apologies if this is a bit of a +1 response, but coming from Rust I really miss ADTs (called enums in rust). Rust's optional Option is vastly superior to everything being nullable - you don't need to annotate @required, the type tells you if it is or not! Rust's Result, which is like Either in Haskell is also a great way to represent fallible operations - quite often the error type is also an ADT with extra data depending on the type of the error. They are also really easy to implement and memory efficient - they are just typed unions from C (although I don't know dart's memory model, maybe everything is behind a pointer anyway).

EDIT To full realise their power you also need some de-structuring support (sometimes called switch/match/case). In rust say you have an ADT like

enum Error { // ADT
    IoError { // 1st variant with named fields
        errno: u32 // unsigned 32-bit int
    }, // 2nd variant with named fields
    ParseError {
        position: usize // unsigned pointer-width int
        msg: String
    },
    UnknownError, // 3rd variant with no fields
}

then the destructuring would look like

match e { // e is an error
    Error::IoError { errno } => {
        // I have access to the fields of the variant here
        // handle the error...
    }
    Error::ParseError { position, msg } => {
        // again I have access to fields
    }
    Error::UnknownError => {
        // nothing to bind here
    }
}

[ivnsch]

@lrhn There may be similarities in the way in which it will be implemented in Dart, but other than that this is unrelated with data classes.

[tchupp]

ADTs are also known as "tagged unions".

In typescript, you may represent the above example as:

type Success = {
  tag: "Success"
  authToken: string;
};

type InvalidCredentials = {
  tag: "InvalidCredentials"
};

type NoNetwork = {
  tag: "NoNetwork"
};

type UnexpectedException = {
  tag: "UnexpectedException"
  error: Error
};

type LoginResponse =
  Success
  | InvalidCredentials
  | NoNetwork
  | UnexpectedException

The tag property is shared by all the different structural types, which allows us to use a switch statement to identify which type we have.

Option<T> from Rust, which is referenced above, is another example of a tagged union.

There is also the concept of an "untagged union", which could simply refer to having one object with nullable fields represent multiple scenarios:

type Option<T> = {
  isPresent: bool;
  value?: T;
};

Untagged unions can also refer to syntax sugar for dealing with nullable types:

_optionalVar?.foo();

Most languages with nullable types can support untagged unions, but Dart clearly has a special understanding since it supports the safe-access operators.

In addition, dart (and similar style languages) provide smart casting (and "instance of" checking) on exceptions with try/catch statements.

Pure OO practices would discourage the use of ADTs, since it involves "casting" an abstract class to a concrete type after doing an "instance of" check. The OO pattern that would replace the need for ADTs is the visitor pattern, but this adds so much overhead just to stay in the OO space that the benefit is often not worth the cost.
Also these languages usually provide exception type checking, which violates that pattern anyways.

I'm not super familiar with how the dart compiler works, but if we are able to identify all the implementation of an abstract class at compile time, it might be possible to remove the need for the else statement at the end a series of is checks.

[ivnsch]

@tchupp Is visitor pattern really a replacement? Doesn't it just move the "instance of" checks to the visitor (I may be mistaken, not super familiar with it)?

Also, I wonder whether ADTs are just convenience for inheritance in OOP, or there's a deeper conceptual difference that makes the "instance of" not violate OOP practices in this case. It feels like may be a fundamental difference between if you're expecting Animal, which can be a Cat or Dog or Result, which can be Ok or Error. A manifestation of this may be that in most languages you can't share data between the types in ADTs, while using inheritance you can. Not sure about this take.

Another take could be that the the "ADT" is just convenience to do do instance of checks in a type safe and concise way. Making the ifs exhaustive, in combination with smart casting, would be no different than just having "ADT"s, except with an uglier syntax.

[jarlestabell]

@i-schuetz I would say you are correct in that there is a deep conceptual difference. In a class (or struct or record), you have the "multiplication" construct of ADTs. What is lacking in Dart at the moment is the "sum" construct of ADTs. I think the sum is better viewed as something different than a special case of inheritance in OOP, although it can to some extent be "simulated" that way.

Here is a bit old, but still very good article about ADTs:
http://static.v25media.com/the-algebra-of-data-and-the-calculus-of-mutation.html

When you get used to sum types, it feels very limited not having them.
For me, TypeScript's tagged unions are quite lacking because pattern matching is missing, which gives you sort of only the first half of the power/convenience of sum types.

[Aetet]

Hey @kevmoo any plans on this?

[LinusU]

I'm really really missing this coming from Swift/iOS to Flutter development.

When dealing with widget/component state, I find it that almost always the state is better described using an ADT rather than several nullable fields. The problem with nullable fields is that it often allows for combinations of values that are simply invalid.

Here is an example from a commercial app I'm currently porting from Swift to Flutter:

class _State {}

class _ChooseProviderState extends _State {}

class _LoadingState extends _State {}

class _ChooseAccountsState extends _State {
  final List<String> accounts;
  final Set<String> selected;

  _ChooseAccountsState(this.accounts) : selected = Set();
}

class _ImportingState extends _State {
  final List<String> imported;
  final List<String> failed;
  final List<String> processing;
  final List<String> queue;

  _ImportingState(this.imported, this.failed, this.processing, this.queue);
}

// ...

  @override
  Widget build(BuildContext context) {
    if (_state is _ChooseProviderState) {
      return _buildChooseProvider(context, _state);
    }

    if (_state is _LoadingState) {
      return _buildLoading(context, _state);
    }

    if (_state is _ChooseAccountsState) {
      return _buildChooseAccounts(context, _state);
    }

    if (_state is _ImportingState) {
      return _buildImporting(context, _state);
    }

    throw Exception('Invalid state');
  }

Apart from being very verbose and cumbersome to type out, there is also no compiler checks that I'm 1) covering all possible states and that 2) there isn't every any other state. This forces me to add a runtime throw in my code.

Now let's compare this to the Swift equivalent:

enum State {
  case chooseProvider,
  case loading,
  case chooseAccounts(accounts: [String], selected: Set<String>),
  case importing(imported: [String], failed: [String], processing: [String], queue: [String]),
}

// ...

  build(context: BuildContext) -> Widget {
    switch state {
    case .chooseProvider:
      return buildChooseProvider(context)
    case .loading:
      return buildLoading(context)
    case .chooseAccounts(let accounts, let selected):
      return buildChooseAccounts(context, accounts, selected)
    case .importing(let imported, let failed, let processing, let queue):
      return buildImporting(context, imported, failed, processing, queue)
    }
  }

Apart from being much much easier to work with, and quickly glance over, it gives me additional compiler guarantees. Here I know that I'm never missing any of the enum cases since the compiler will complain. I also don't have to add a runtime throw, since the compiler can guarantee that execution will never continue after the switch statement.

I would absolutely love to see this in Dart 😍 is there anything I can do to move this forward?