Skip to content

questions #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

questions #1

wants to merge 5 commits into from

Conversation

chenyan2002
Copy link
Owner

No description provided.

@@ -151,6 +152,7 @@ A `tuple` type is an ordered _fixed length_ sequence of values of specified type
tuple<u64, string> // An integer and a string
tuple<u64, string, u64> // An integer, then a string, then an integer
```
^^^ Is `tuple<>` the same as `_`?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it isn't the same. That is a common question though, so something we should explicitly cover in the doc.

@@ -175,6 +177,10 @@ Records are similar to C or Rust `struct`s.

> User-defined records can't be generic (that is, parameterised by type). Only built-in types can be generic.

^^^ Not sure I understand this note. I assume WIT cannot have generic types at all?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wit has a few builtin types which are effectively generic, such as stream<T>, future<T>, result<O, E>, and Option<T>. But it does not support user-defined generics at this time.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. These can be done with syntactic restrictions, and not something the user can define. To me, that's not really a generic, because you cannot define a function that takes stream<T> as an argument. T has to be a concrete type at the interface level.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I think of it is: we have some built in generic types, but we don't support generic functions.

@@ -175,6 +177,10 @@ Records are similar to C or Rust `struct`s.

> User-defined records can't be generic (that is, parameterised by type). Only built-in types can be generic.

^^^ Not sure I understand this note. I assume WIT cannot have generic types at all?
^^^ Do we consider `record T { a: T }` as a valid type, which is isomorphic to empty type?
^^^ Is `record {}` the same as `_`?
Copy link

@dgohman-fastly dgohman-fastly Feb 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's different. I think I said earlier that _ is a unit type, but more precisely: _ is a special-case in result and other types that use it meaning "no value".

The component-model went back and forth on this topic a few times. Should functions return multiple values, which could be zero values? Or should they return a single value which could be a tuple, which could be a 0-tuple? Valid arguments can be made either way. For better or worse, we ended up going with functions that can return multiple results.

@@ -191,6 +197,9 @@ Variants are similar to Rust `enum`s or OCaml discriminated unions. The closest

> User-defined variants can't be generic (that is, parameterised by type). Only built-in types can be generic.

^^^ Do we allow recursive types, e.g., `variant List { head: i32, tail: option<List> }`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not today, but this is a commonly-requested feature that we plan to add in the future.

@@ -191,6 +197,9 @@ Variants are similar to Rust `enum`s or OCaml discriminated unions. The closest

> User-defined variants can't be generic (that is, parameterised by type). Only built-in types can be generic.

^^^ Do we allow recursive types, e.g., `variant List { head: i32, tail: option<List> }`
^^^ Do we allow `variant {}`, which is an empty type?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No; to make it easier for language bindings, I believe we disallow empty variants, because not all source languages have a nice way to express such things.

@@ -204,6 +213,7 @@ enum color {
```

This can provide a simpler representation in languages without discriminated unions. For example, a WIT `enum` can translate directly to a C++ `enum`.
^^^ Is `enum` a syntatic sugar of `variant`?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's a specialization.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. So it's not quite a syntactic sugar. The underlying representation can be different from the de-specialized types.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that's a good point. The semantics of specializations are equivalent to non-specialized forms, but in general, the representation and implementation code can be different. That said, I don't recall enum doing anything different from variant in practice.

An example of a specialization that does differ from its non-specialized form is string; it's equivalent to list<char>, but while list<char> is effectively UTF-32, string can use other encodings such as UTF-8 or UTF-16. They store the same values, just represented differently.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if an interface imports string, and the user provides list<char> type. Does it still compose?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, they are considered distinct types, so they don't compose like that. So you're right, they are not sugar.

@@ -269,6 +281,7 @@ flags allowed-methods {
```

> A `flags` type is logically equivalent to a record type where each field is of type `bool`, but it is represented more efficiently (as a bitfield) at the binary level.
^^^ Is there a size limit for `flag`?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment it's 32, just to make things easy for bindings generators. But that could be raised in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants