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

Change variable binding syntax #170

Closed
PaulBone opened this issue May 21, 2019 · 2 comments
Closed

Change variable binding syntax #170

PaulBone opened this issue May 21, 2019 · 2 comments
Assignees
Labels
component: compiler Concerning the compiler meta: triaged Has the issue been triaged yet? skill: mercury status: resolved Changes merged (sometimes with edits and not always through the github UI). type: enhancement

Comments

@PaulBone
Copy link
Member

At the moment variable bindings allow a variable to be available after branching control flow if all paths either bind it or return early (not implemented):

if (...) { 
    x = ...
} else {
    x = ...
}
print!(x)   % We can use x here.

But it was pointed out to me that this is unintuitive, by more than one
person. In my own experience this is okay (it's how Mercury works, and no
one seems to worry about it / notice it there). But it seems I have some biases and instead we'll implement it as:

val x
if (...) { 
    x = ...
} else {
    x = ...
}
print!(x)   % We can use x here.

And track that work in this bug.

@PaulBone PaulBone added type: enhancement skill: mercury component: compiler Concerning the compiler meta: triaged Has the issue been triaged yet? status: accepted A bug we intend to fix it. labels May 21, 2019
@PaulBone PaulBone added this to the Ergonomics 2019 milestone May 21, 2019
@PaulBone PaulBone self-assigned this May 21, 2019
@brendanzab
Copy link

brendanzab commented May 23, 2019

Yeah, this is pretty much how Rust does it!

let x; // `x` is uninitialized here
if ... {
    x = ...;
} else {
    x = ...;
}
println!("{}", x); // can only use `x` here because it was assigned in both arms

@PaulBone
Copy link
Member Author

Yeah, this is pretty much how Rust does it!

I presume that:

let x; // `x` is uninitialized here
if ... {
    x = ...;
} else {
    not_x = ...;
}
println!("{}", x);

Is not legal.

@PaulBone PaulBone added status: resolved Changes merged (sometimes with edits and not always through the github UI). and removed status: accepted A bug we intend to fix it. labels Jun 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: compiler Concerning the compiler meta: triaged Has the issue been triaged yet? skill: mercury status: resolved Changes merged (sometimes with edits and not always through the github UI). type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants