Proposal for the Dyn Type #154
Conversation
There was a problem hiding this comment.
Thanks for pinging me on this, @spignorel! I think my biggest overall question would be how we would document, explain, and expose this to users; a lot of the approximations, for instance, seem very reasonable but may take users by surprise unless we can offer good feedback as early as possible.
|
|
||
| The analyzers are run for one callable at a time (same as it is the case today). They will be run once in (more or less) the same way as they are today, and produce the same attribute they are today - i.e. the first pass of the analyzers analyzes the requirements of the callable under the assumption that all arguments are non-dyn values. | ||
|
|
||
| Additionally, we will run the analyzers once for each parameter of the callable. This pass will produce an additional attribute per parameter that indicates the required runtime capability if a specific parameter is `dyn` instead of non-`dyn`. We hence end up with n+1 attribute on the callable, where n is the number of parameters. For each call to the callable, the required capability for that call is given by the sum of the required capabilities for the callable itself plus those for of the `dyn` arguments. |
There was a problem hiding this comment.
What will these attributes be called? If they exist on the final AST output by the compiler, then they will need to be public parts of the Core library API and would then need API review as well.
|
Although dyn as a type was originally my idea, I think my opinion now is that dyn should not be a type, but rather an internal compiler property for values. We don't plan to expose dyn to users (and potentially it may never need to be exposed, given our inference rules), so I think it would be better to avoid cementing it in Q#'s type system. For the compiler's static analysis, I think we only need:
So I'm not sure if this should be a QEP at all, since we didn't write a QEP for the earlier static analysis of hardware capabilities before, but left it as an internal compiler implementation detail. |
|
Are we in agreement on this now? @spignorel do you need to update the proposal based on the latest from @SamarSha above? |
This proposal introduces a Dyn type to reflect values that are only known at runtime.