Literal types?

[3xau1o]

I've learning F# for some days and coming from Typescript and Scala context i miss declaring a literal types ( types defined by numeric and/or string values )

Literal types in typescript, source:

// Literal union type
type Easing = "ease-in" | "ease-out" | "ease-in-out";

const someEasing : Easing =  "ease-in"

Scala also supports literal types, source

// the following constant can only store ints from 1 to 3
val three: 1 | 2 | 3 = 3

val one: 1 = 1                     // val declaration
def foo(x: 1): Option[1] = Some(x) // param type, type arg
def bar[T <: 1](t: T): T = t       // type parameter bound
foo(1: 1)                          // type ascription

Rescript which is somehow related to F# because of its OCaml influence has Polymorphic Variant, which allow to use strings and numbers literals as types by using a intentional different syntax.

// Literal union type
type easing = [ | #easeIn | #easeOut | #easeInOut ]

let someEasing : easing =  #easeIn

// the following constant can only store any integer from 1 to 3
let three: [ #1 | #2 | #3] = #3

Could that be possible on F#, using literals as types?

[pblasucci]

So, very technically, no -- F# doesn't have this feature the way some other languages do. However, given your very limited examples, I don't see anything that cannot be accomplished with a garden-variety Discriminated Union. 🤷‍♂️ But presumably, a more sophisticated example would reveal the limitations/trade-offs of not having this feature.

[3xau1o]

Indeed the few examples above can be accomplished by using union types and map each type to a literal using pattern matching.
About use cases, i can think of every day use by modeling Json literal fields, those that have used typescript types may understand how naturally fits there, because they allow to limit the number of possible values for a field instead of any string and/or any number, however i understand that in F#, things are or can be done differently.

A quote from rescript docs:

Poly variants are great for JavaScript interop. For example, you can use it to model JavaScript string and number enums like TypeScript, but without confusing their accidental usage with regular strings and numbers.

[3xau1o]

for example:

// you can also represent a JSON-like data type in F# with records
type AppMetadataGeneral = {
  version: number
  type: string
  runtime: string
}

// putting specific domain values as in typescript/rescript
type AppMetadataSpecific = {
  version: 1 | 2 | 3
  type: 'mac' | 'win' | 'linux' | 'ios' | 'android'
  runtime: '.net core' | 'mono'
}

the second will prevent from putting a value like 'JVM' on runtime or 4 on version, this may also be done with enums, but literals feels the right way for me, they avoid a separate definition and import/export.

[abelbraaksma]

I'm not entirely sure whether you mean "literal" as in a compile-time literal that's like a constant type that restricts the types of a constant (i.e. with [<Literal>] attribute) declaration? Or is this type available for variables and would you get a runtime exception when you assign it the wrong value?

While not a perfect equivalent, literals can be expressed as Enum types, just as in C#:

type OTT = One = 1 | Two = 2 | Three = 3

[<Literal>]
let Foo = OTT.One

Or even like this, which, granted, nobody should write:

type ``123`` = ``1`` = 1 | ``2`` = 2 | ``3`` = 3

[<Literal>]
let Foo = ``123``.``1``

I kinda like the idea of limited string literals as a type, but I don't know if it adds enough value to the already available normal literals. I mean, if this is compile-time only, you could just as well create a few literals in a module that you'd call Constants or something like that.

[3xau1o]

A compile time check would be already useful, indeed typescript does type erasure so it's only checked at compile time, and i believe Scala does something similar, check at runtime would be exceptional feature but also more intrusive i believe, and not sure if there are many benefits over compile time check and some level of type erasure.

[3xau1o]

A compile time approach could be checking matches for the strings literal subset "ease-in" | "ease-out" | "ease-in-out" at compile time, while the underlying type at runtime would be plain string

// Checked at compilation
type atCompileTime =  "hello" | "world"  |  1u | 16u

// Compiled down to ↓
type atRuntime =  String | Uint

[3xau1o]

The underlying idea (from using too much typescript) would be to avoid external enums or constants definitions, also avoiding manual checks for specific values, delegating more work to the compiler (as in typescript) having already
the possible types and values defined in the type itself.

[abelbraaksma]

The syntax above touches a little on Erased Union types, see #538. That proposal doesn't support multiple-typed constants, but it would allow you to express most of the above, just not as a Literal.

I don't really like the "compiled down to" as that would erase the validation. If the type syntax means that only these four values are allowed, it should be more than just a type-erased union, and instead be some kind of wrapper that validates construction of such types. I don't think that's feasible, we have enums for that, and string-enum libraries exist, I believe.

[abelbraaksma]

Reading the referenced thread #1195 it becomes clearer what the idea is behind this. Reading back my own comments I didn’t quite get the proposal.

[cartermp]

This has been briefly discussed in this issue: #656

I'd be curious what @dsyme's take is now that some preliminary work has landed that could support a feature like this in the future.

[3xau1o]

I understand some points by @dsyme

Mroe realistic would be a typescript-like combination of literals-as-types plus adhoc unions, e.g. "CDN" | "USD" | int
#656 (comment)

I am aware that these kind of APIs also often want to constrain to particular values, e.g. (int32|int64|"*"|"auto") where, for example, only specific constant strings are admitted into the type.
#538 (comment)

Those are enough to think the simple feature i am suggested, is already taken into account, also many of the why? have been discussed in threads.

[3xau1o]

I believe the benefits and drawbacks should be a little more clear now, than in 2018 where discussions about this started, because some compiler works has been done, and more people has become familiar with modeling constant data in types the way typescript allows.
Also the fact that also Scala has literal types and Rescript also supports it via polymorphic variants is proof to me that some functional languages are looking towards.

[dsyme]

This is now back in scope, see #1195