questions #1
questions #1
Conversation
| @@ -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 `_`? | |||
There was a problem hiding this comment.
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? | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 `_`? | |||
There was a problem hiding this comment.
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> }` | |||
There was a problem hiding this comment.
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? | |||
There was a problem hiding this comment.
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`? | |||
There was a problem hiding this comment.
I see. So it's not quite a syntactic sugar. The underlying representation can be different from the de-specialized types.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
So if an interface imports string, and the user provides list<char> type. Does it still compose?
There was a problem hiding this comment.
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`? | |||
There was a problem hiding this comment.
At the moment it's 32, just to make things easy for bindings generators. But that could be raised in the future.
No description provided.