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

Lower the restrictions on if let #2186

Closed
ghost opened this issue Oct 21, 2017 · 11 comments
Closed

Lower the restrictions on if let #2186

ghost opened this issue Oct 21, 2017 · 11 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@ghost
Copy link

ghost commented Oct 21, 2017

Sometimes, a construct like the following one is used.

let a = {
    let b = ...;
    // ...
};

I think it would look prettier with if let (it's also idiomatic in many lisps)

let a = if let b = ... {
    // ...
};

But rust can likely fail with either https://doc.rust-lang.org/error-index.html#E0317 or https://doc.rust-lang.org/error-index.html#E0162 if in the place of ... we have a known value

@oli-obk
Copy link
Contributor

oli-obk commented Oct 23, 2017

I'm not sure I understand. if let and let have completely different semantics.

Do you mean to yield two values?

let (a, b) = {
    // ...
    (a_value, b_value)
};

@DaseinPhaos
Copy link

DaseinPhaos commented Oct 23, 2017

@oli-obk

I guess what @fwrs means is that, as let b = ... is a irrefutable pattern matching, no else branch would be reachable or needed. Thus the proposed semantics is legit, and would be prettier and more idiomatic comparing to the current construct.

A concrete example:

Current

let a = {
    let b = 1;
    b + 1
};

Proposed

let a = if let b = 1 {
    b + 1
};

I'm not sure the above incentive is strong enough though.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 23, 2017

I don't understand why you'd want an if there. There's no conditional code execution going on

@scottmcm
Copy link
Member

I think I'd expect it to be something more SML-like, maybe

let foo_squared =
    let x = foo()
    in x * x;

(Though I'm not convinced that's worth supporting when the block works fine.)

@scottmcm scottmcm added the T-lang Relevant to the language team, which will review and decide on the RFC. label Oct 26, 2017
@eddyb
Copy link
Member

eddyb commented Oct 26, 2017

You can write it like this if you want to 🤷‍♂️:

let a = { let b = 1;
    b + 1
};

@eddyb
Copy link
Member

eddyb commented Oct 26, 2017

There's also this, which is closer in semantics to let ... in (in terms of temporary scopes):

let a = match 1 {
    b => b + 1
};

@eaglgenes101
Copy link

eaglgenes101 commented Oct 29, 2017

I'd suggest using a new keyword "with" for a construct like this. It already has similar usage as a keyword to specify RAII-style object disposal in other languages, and it suggests the right idea to someone not familiar with it.

Something like:

let a = with b = 1 {
    b + 1
}

@Aceeri
Copy link

Aceeri commented Nov 3, 2017

Introducing language concepts for seldom useful stuff like this would only confuse people. You don't even save any time from typing it out and it removes no boilerplate.

@eaglgenes101
Copy link

eaglgenes101 commented Nov 19, 2017

Fair enough. At the same time, I don't want to be put in the position where I'm cracking my head over rust code for hours, just to realize that "if" is syntactically overloaded to also "plant" variable within scopes.

See c++ operator overloading and why some people will argue for days on end why it's a bad thing even though it makes many expressions cleaner.

@eddyb
Copy link
Member

eddyb commented Nov 19, 2017

@eaglgenes101 But it's not, the let in if let and while let is what's declaring the variables.

@Centril
Copy link
Contributor

Centril commented Apr 26, 2018

This seems resolved per #2086.

@Centril Centril closed this as completed Apr 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

7 participants