Stream: compiler development

Topic: Wildcard in opaque types

Luke Boswell (Jan 01 2025 at 22:15):

Should it be possible to use a wildcard inside an opaque type? This feels like something I should be able to do. I understand I can use a type variable, but that seems unnecessary.

module [Custom]

Custom := {
    number : Frac *
}

── WILDCARD NOT ALLOWED HERE in example.roc ────────────────────────────────────

The definition of Custom includes a wildcard (*) type variable:

4│      number : Frac *
                      ^

Opaque type definitions may not use wildcard (*) type variables. Only
named type variables are allowed.

Sam Mohr (Jan 01 2025 at 22:16):

I think we should just remove wildcards and make this whole class of edge cases disappear

Sam Mohr (Jan 01 2025 at 22:17):

And then the answer is that you need to use a variable, because that ensures that all type cardinality is exposed outside of types

Sam Mohr (Jan 01 2025 at 22:18):

Otherwise, the usage of Custom sans type args doesn't always mean that Custom is a static type

Sam Mohr (Jan 01 2025 at 22:18):

Which seems like a trust issue

Sam Mohr (Jan 01 2025 at 22:19):

Even without removing wildcards, I still think you should need to write

Custom frac := {
    number : Frac frac
}

and use it as Custom * or Custom _ or Custom frac

Luke Boswell (Jan 01 2025 at 22:20):

I've currently just used a concrete type F32, and expect my API consumers to convert to that. Minor inconvenience if they have a Dec or F64

Sam Mohr (Jan 01 2025 at 22:20):

That's probably fine

Sam Mohr (Jan 01 2025 at 22:21):

Why not F64? Seems constrictive to use the smaller float type

Luke Boswell (Jan 01 2025 at 22:21):

I want a floating value in the range 0-1

Luke Boswell (Jan 01 2025 at 22:21):

I definitely don't need an F64 precision

Sam Mohr (Jan 01 2025 at 22:21):

Oh, yeah, makes sense

Last updated: Jul 26 2025 at 12:14 UTC