Skip to content
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

Interaction between 'let' and name section #37

Closed
manoskouk opened this issue Sep 14, 2020 · 3 comments
Closed

Interaction between 'let' and name section #37

manoskouk opened this issue Sep 14, 2020 · 3 comments

Comments

@manoskouk
Copy link
Contributor

Are there any thoughts about how 'let' should interact with the name section? I see two issues:

  • Since local indexes shift inside the scope of 'let', a consumer of the name section (e.g. debugger) has to track those scopes (or at least the number of bound locals).
  • There is no way to assign names to let-bound variables in the name section.

On a more general note, since 'let' seems to be creating some complications, maybe it should be removed and replaced with the rule that non-defaultable locals must be (trivially) provably initialized before use.

@rossberg
Copy link
Member

Agreed, the name section should eventually support let.

since 'let' seems to be creating some complications, maybe it should be removed and replaced with the rule that non-defaultable locals must be (trivially) provably initialized before use.

Yeah, but that would amount to control-flow-dependent type checking. Such systems tend to create considerably more complications, and a "trivial" approximation quickly becomes wishful thinking -- there always is another useful case that somebody wants to see handled.

@RossTate
Copy link

If label types are extended to be able to specify that certain locals must be defined, that addresses all those complications.

@rossberg
Copy link
Member

Let was removed, so this is obsolete.

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

No branches or pull requests

3 participants