Type System for Compile-Time and Run-Time Existential Values #14
Conversation
|
|
tangent-vector
left a comment
tangent-vector
left a comment
There was a problem hiding this comment.
This proposal looks great. I've walked through the plan as documented here and it seems like all the points are covered and it should be implementable on top of the current compiler codebase (rather than requiring any significant rearchitecture or overhauls).
This would be a really nice feature to get into the language ASAP, so that we can give our users (and ourselves) more confidence in the robustness of code that uses interface-typed parameters/variables/etc.
juliusikkala
left a comment
juliusikkala
left a comment
There was a problem hiding this comment.
I like this proposal a lot, I've already encountered a few situations where these would've been helpful. I especially appreciate making some the default behaviour for 2026.
| 1. If a function returns `some IFoo`, then all return statements must return values of exactly the same type. | ||
| 1. If a function contains a `out some IFoo` parameter, then all values assignmened to the parameter must have exactly the same type. | ||
| 1. Two different var decls of `some IFoo` type are considered to have **different** types. | ||
| 1. A `dyn IFoo` type is valid only if `IFoo` is an interface type with `dyn` qualifier. |
There was a problem hiding this comment.
This line reads a bit confusingly (given the example provided later in the doc dyn IFoo d = f; and dyn IFoo v1;).
For clarification, this means that given the following:
dyn interface IDyn{};
some interface ISome{};
struct ISomeImpl : ISome {};
-
I cannot do (in a function's scope):
dyn ISome dynVar; -
I can do (in a function's scope):
dyn IDyn dynVar; -
I can do (in a function's scope):
some ISome someVar = ISomeImpl();
dyn ISome dynVar = someVar;
- I can do (in a function's scope):
dyn ISome dynVar = ISomeImpl();
There was a problem hiding this comment.
I don't think some can be used on interface type, from the proposal, some is supposed to be used only on var decl.
There was a problem hiding this comment.
The understanding is correct, although I would comment that IInterface() is never a valid expression. You can construct an interface typed value using the interface type.
| Any type that conforms to one or more `dyn` interface is subject to these restrictions: | ||
|
|
||
| 1. The type itself must be an ordinary data type, meaning that it cannot contain any fields that are opaque or non-copyable or unsized. |
There was a problem hiding this comment.
Is this section intentionally omitting unless language version is 2025 or -enable-experimental-dynamic-dispatch flag is present:?
(I ask since this PR is a breaking change without the clause)
There was a problem hiding this comment.
I don't think we allow opaque type in an interface that can be used in dynamic dispatch for now.
So I guess this is intentionally omitting.
There was a problem hiding this comment.
Actually, I think my memory is correct. Look at this line.
Another big down side is that our dynamic dispatch logic can only handle ordinary data types. If a type implementing an interface contains opaque types such as
Texture2D, the dynamic dispatch pass will fail and give user confusing error messages
There was a problem hiding this comment.
Yes, this applies in all cases regardless of language version or experiemental flag setting. We can never support opaque types in dynamic dispatch.
| { | ||
| out = f; // error: type mismatch. | ||
| out.computeFoo(1.0); // OK, calling mutable methods on a some type. | ||
| dyn IFoo d = f; // OK, assigning `some IFoo` to `dyn IFoo`. |
There was a problem hiding this comment.
This should error, 1. A `dyn IFoo` type is valid only if `IFoo` is an interface type with `dyn` qualifier..
There are no exceptions to this rule, interface types are not automatically assigned dyn.
6 participants
No description provided.