Unboxed wrapper types (newtypes)

[lpil]

Support creation of type wrappers that function like custom types of a single field, require explicit boxing and unboxing, and at runtime all boxing is erased so there is no runtime overhead.

i.e. Cents wraps an Int. At runtime it is just an Int, no record wrapper.

This is called a newtype in Haskell.

What should the syntax be?

[CrowdHailer]

Can it using the existing syntax but just be an optimisation on single value types.

e.g.

type Cent{
  Cent(Int)
}

Because there is only ever one variant is there a reason this needs to produce the tuple {:cent, int} it should never be matched on. I think?

Otherwise I would expect something like

type Cent = Int

But I think that is already used for type aliases.

[lpil]

That is the approach that OCaml takes but at the moment I would like to have consistency in the code generation in order to make Erlang FFI more straightforward and to have fewer exceptions to the rules of the language.

At the very least I would like to see what syntax ideas we can come up with.

type Cent = Int

What would the syntax be for boxing and unboxing the newtype in this case? It seems there is no constructor?

[CrowdHailer]

I guess construction makes sense if it looks like

let cents = Cent(5)
let Cent(number) = cents

Perhaps that suggests a syntax of

type Cent(Int)

Questions is there interest in a type that at runtime just puts values in a tuple.
i.e. type Coordinate(x: Int, y: Int) makes {x, y}

Such a thing might be useful for how erlang sometimes represents times or ip addresses.

In which case type Cent(Int) I would expect to make a one element tuple. 🤔

[lpil]

I don't plan to have the ability to construct records without a tag. If this is desired it can be achieved using a newtype over a tuple.

I don't think the syntaxes above fit the Gleam pattern of type TYPE_NAME VALUE_CONSTRUCTORS. Will have to give this more thought.

[eterps]

i.e. Cents wraps an Int. At runtime it is just an Int, no record wrapper.

In Nim that would be type Cent = distinct Int

[lpil]

ooh thanks! I had not looked at Nim

[eterps]

Nim's way to construct such a value also makes me think of the units of measure notation in F# but that's a completely different feature.

[lpil]

Wow, that's amazing. F# has so much interesting stuff in it, I need to learn it!

[eterps]

Wow, that's amazing. F# has so much interesting stuff in it, I need to learn it!

In that case I'd recommend reading this book, it gives a good idea what Gleam can be for the BEAM ecosystem in very practical terms.

[lpil]

Oh dear, my just as I thought I was starting to get through books faster than I collected them 😆

Thanks for the recommendation, it sounds great

[lpil]

Just ordered a copy! :)

[oneness]

This feature would be great addition. I am thinking of using some reserved keyword to make it explicit. Such as:

type Cent wraps(Int) or type Cent aliases(Int)

where wraps or aliases (or any other better name?) that are reserved keywords that constructs newtype. During the compilation, we can just use unwraps or unaliases counterparts to do the type erasure.

[lpil]

If all wrapper types use the same constructor it becomes hard to know what type is to be constructed during type inference. If given an Int and there are two wrappers if Int then we would need a type annotation to continue, which is somewhat more verbose.

[Aloso]

Kotlin's equivalent are inline classes.

About the syntax, I'm in favor of just adding a keyword, for example:

value type Cent {
  Cent(Int)
}

or

wrapper type Cent {
  Cent(Int)
}

This has several advantages:

• It looks familiar
• It is easy to search for on Google
• It can easily be extended, if we want to support multiple constructors or multiple fields in the future

[lpil]

Thank you for the Kotlin example, very useful. I quite like the modifier inlined for this, it matches opaque.

pub inlined type Cent {
  Cent(Int)
}

Though perhaps that's confusing when using with opaque? Does the order matter?

pub opaque inlined type Cent {
  Cent(Int)
}

pub inlined opaque type Cent {
  Cent(Int)
}

[brightly-salty]

I'd be interested in attempting this, although it will probably be bigger/take a while. It looks like we need to introduce a new syntax for the type modifier "inlined", similar to "opaque", which semantically functions similar to "opaque" in the type system and produces an error if there is more than one constructor, or the constructor has a different name than the type name. Is this right?

[lpil]

Yes, that's right! The type name and the constructor name could be different though.

[michallepicki]

As an elixirist I would like it to be something like that (example syntax):

type A {
  int()
  Wrapped(Int)
}
type B {
  int()
  Other(String)
}

so that a custom type with newtype can have more than one constructor, only max one per basic type, which works thanks to guards at runtime, and they are incompatible. So to convert from A int to B int I'd have to:

assert A.int(i) = a
B.int(i)

[michallepicki]

For completeness of the thread, there was a closed PR from @brightly-salty #931, and now @lpil is working on this at #2330

[cubiquitous]

both are closed now