Re: Proposal: if variable initialization

Same sentiments, and I am pleased with how golang handles this common desire. Another idea I had is a `for` statement with only one expression of declarations, or even a new use for the dead `with` statement (conveniently named). On Tue, Mar 20, 2018 at 3:57 PM, Rodrigo

Re: Proposal: if variable initialization

On 03/22/2018 11:21 PM, Naveen Chawla wrote: I'm still not seeing a compelling case for not allowing `const` / `let` declarations to be evaluated as expressions. Or I've missed it. Yes, I think there is a compelling case for not allowing `const` / `let` declarations to be evaluated as

Re: Proposal: if variable initialization

gt; >> - > >> >> > >> >> Isiah Meadows > >> >> m...@isiahmeadows.com > >> >> > >> >> Looking for web consulting? Or a new website? > >> >> Send me an email and we can get started. > >>

Re: Proposal: if variable initialization

Send me an email and we can get started. >> >> www.isiahmeadows.com >> >> >> >> >> >> On Wed, Mar 21, 2018 at 6:25 PM, Sebastian Malton >> >> <sebast...@malton.name> >> >> wrote: >> >> > Sorry if I mis

Re: Proposal: if variable initialization

t; >> > Sorry if I missed a message but would such an initialization be only > >> > available in the first `if` block or also in the subsequent `else if` > and > >> > `else` blocks? > >> > > >> > Sebastian Malton > >> > > &

Re: Proposal: if variable initialization

tian Malton >> > >> > >> > Original Message >> > From: isiahmead...@gmail.com >> > Sent: March 21, 2018 6:18 PM >> > To: mikesam...@gmail.com >> > Cc: sebast...@malton.name; es-discuss@mozilla.org >> > Subject:

Re: Proposal: if variable initialization

Per-iteration scoping would work just as it does with `for (const foo of bar) { ... }` now, and if it were to make it in (I'm mildly against the feature, BTW), I'd prefer it to be per-iteration like that. - Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website?

Re: Proposal: if variable initialization

Obviously scoped, agreed, but again how would you allow scoped initialization upon each iteration, or is it your preference not to allow that? (again, initializers-as-expressions allows that, despite the other concerns). On Sun, 25 Mar 2018 at 10:57 Isiah Meadows wrote:

Re: Proposal: if variable initialization

1. My concern with `while` is that it's a little too duplicative of C-style `for` functionally (although it's not an exact partial clone). That's why I backtracked on it right as I proposed it (within the same email). 2. The scope would have been just like `if`, where it's scoped to the body with

Re: Proposal: if variable initialization

I understand the fear about "bad code" potentially sprouting from it. I guess I'm not as bothered as long as I can do what I want. So it's a matter of how heavily weighted the "potential bad practice" concern is over developer power. The advantage is that it's as powerful as the developer wants

Re: Proposal: if variable initialization

I disagree, I feel it's too clever. It'd make sense in a control flow statement where in the alternate branch, the value is meaningless/useless/ineffable/etc. (and this is why `for` loops commonly allow such syntax already), but in ordinary function calls, it seems like it's just trying to golf

Re: Proposal: if variable initialization

I don't know why `foo(let x = 10)` would be a bad practice or hurt readability. I find it perfectly readable and with obvious meaning! ```js foo(const x = 10) bar(x) ``` vs ```js const x = 10 foo(x) bar(x) ``` I also find it "clean". So I guess these aren't really useful

Re: Proposal: if variable initialization

@Naveen, I think it's best to avoid this road altogether and keep initialization clean, even though assignment isn't. The proposal is that given `for(;;)` hence `if(;)` instead of given `x=y` hence `let x=y`. But yes, `if( x = 5)` is already allowed, but it's confusing and hard to read.

Re: Proposal: if variable initialization

unlike all other popular c-derivatives, javascript is the only one that's *not* a blocking-code language by design. maybe tc39 should do some outreach to educate the many language-designers and polyglots who only know blocking-code patterns of this simple fact. as i've said before, adding

Re: Proposal: if variable initialization

I'm still not seeing a compelling case for not allowing `const` / `let` declarations to be evaluated as expressions. Or I've missed it. As was noted, `if(x = 5)` is already allowed. Is `if(const x = 5)` really that much of a stretch? To answer a concern about a function call like

Re: Proposal: if variable initialization

Probably true, more so than the `if (var ...)`/etc. (which can't be as easily desugared). My `else` variant desugars more to something that is also easily simulated, and it's a less common case: ```js let foo = bar else return baz; // Desugared let _tmp = bar; if (tmp == null) return baz; let

Re: Proposal: if variable initialization

That strikes me as territory the 'do expression' proposal https://github.com/tc39/proposal-do-expressions is more fitted for: const x = do { if (c) expr; else { ... } }; What I'd like for this proposal is something that works consistently and obviously for all blocks with a parenthesised

Re: Proposal: if variable initialization

On Thu, Mar 22, 2018 at 3:50 AM, Isiah Meadows wrote: > > I do have one other related thing I'd like to see: add a `let foo = > expr() else { ... }` variant, with a line terminator restriction > before the `else` so it can't be confused with an `else` within an > `if`. >

Re: Proposal: if variable initialization

I agree, the `switch` statement was not on my radar and I don't see that need, it's the scoped `if` constructs that would make code cleaner. On Thu, Mar 22, 2018 at 8:50 AM, Isiah Meadows wrote: > > I get the nagging feeling someone is eventually going to complain that >

Re: Proposal: if variable initialization

I get the nagging feeling someone is eventually going to complain that this feature is unnecessary and smells too much like `let` blocks: - Relevant thread: https://esdiscuss.org/topic/revive-let-blocks - How it ended:

Re: Proposal: if variable initialization

Not just let-scopes, but the introduction of `async/await` also welcomes the introduction of if-scoped variables. if (const data = await collection.find({}).toArray(); data.length > 10) { console.log(data); } else if (data.length > 0) { console.log(data); } else {

Re: Proposal: if variable initialization

Fun fact: you'd be surprised how many non-trivial JS stuff there is. If you've ever used jQuery selectors, you've used a selector engine implemented in JS [1], which uses quite a few advanced data structure and algorithm techniques. Not all JavaScript is inherently async, nor does it need to be.

Re: Proposal: if variable initialization

l.com > Sent: March 21, 2018 6:18 PM > To: mikesam...@gmail.com > Cc: sebast...@malton.name; es-discuss@mozilla.org > Subject: Re: Proposal: if variable initialization > > I'm personally very much *for* this `if (var ...; cond) { ... }` > syntax. I couldn't tell you how many ti

Re: Proposal: if variable initialization

...@malton.name; es-discuss@mozilla.org Subject: Re: Proposal: if variable initialization I'm personally very much *for* this `if (var ...; cond) { ... }` syntax. I couldn't tell you how many times I would've liked something to that effect, since that's probably one of my biggest areas of boilerplate

Re: Proposal: if variable initialization

I'm personally very much *for* this `if (var ...; cond) { ... }` syntax. I couldn't tell you how many times I would've liked something to that effect, since that's probably one of my biggest areas of boilerplate. I would also be in favor of `if (var ...) { ... }` as a shorthand that guards `!=

Re: Proposal: if variable initialization

@mike yes that’s true, but issues with blocking-code javascript data-structures/algorithms are rarely the reason web-projects fail. they fail largely due to unresolvable integration-level io/workflow issues (that are unique only to javascript). block-scoping fixes the insignificant former,

Re: Proposal: if variable initialization

TIL On Wed, Mar 21, 2018 at 2:29 PM, kai zhu wrote: > /*jslint > stupid: true > */ > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton wrote: > Because block-level scoping is a very good way to avoid certain bugs and > is easier to reason about. Especially when considering project successors. > +1. function-scoped variables in loop bodies caused tons of

Re: Proposal: if variable initialization

i'm not trolling. unlike javascript, most other languages deal near exclusively with blocking-code, which is only applicable to low-level library-code in javascript (that pretty much anyone can write). at higher-level integration-stuff dealing with non-blocking io, these blocking-code

Re: Proposal: if variable initialization

I have used the desugared version and found that what seemed obvious to me, that the purpose of the block was to limit the scope, was not obvious to other developers on  my team. If this proposal moves forward I think it should include switch and while in addition to if. On Wednesday,

Re: Proposal: if variable initialization

This is just trolling that seems intended to derail the discussion. On Wed, Mar 21, 2018 at 10:21 AM, kai zhu wrote: > how is any of this less-confusing than a simple style-guide of > pre-declaring all variables @ the beginning of a function? > again, there’s zero

Re: Proposal: if variable initialization

PMTo: mikesam...@gmail.comCc: es-discuss@mozilla.orgSubject: Re: Proposal: if variable initialization how is any of this less-confusing than a simple style-guide of pre-declaring all variables @ the beginning of a function?again, there’s zero legitimate reason why _javascript_ even needs block

Re: Proposal: if variable initialization

how is any of this less-confusing than a simple style-guide of pre-declaring all variables @ the beginning of a function? again, there’s zero legitimate reason why javascript even needs block-level scoping of variables (and arguing because other languages have it is not a reason). you're just

Re: Proposal: if variable initialization

On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo wrote: > My proposal is to keep it simple and implement the if-assignment `if( > const o = ...; ! o ) { ... }` mimicking the `for(;;)` assignment > behavior. > Fair enough. If the assignment is separate from the condition, then

Re: Proposal: if variable initialization

My proposal is to keep it simple and implement the if-assignment `if( const o = ...; ! o ) { ... }` mimicking the `for(;;)` assignment behavior. That way we can scope a variable to the `if` block and we can do that *separately* from assignment. Assigning and comparing at the same time opens up

Re: Proposal: if variable initialization

On Tue, Mar 20, 2018 at 3:57 PM, Rodrigo wrote: > Proposal: inline let/const statements to declare and initialize > variables within if statements, so that temporary variables exist only > within the if/else block scope. > With setters you can get some oddities because

Re: Proposal: if variable initialization

@thomas, no. i'm serious in my opinion that let and const were mistakes. -kai > On Mar 21, 2018, at 9:01 PM, Thomas Grainger wrote: > > Is this sarcastic? > > On 21 Mar 2018 12:58, "kai zhu" > wrote: > this is why let and

Re: Proposal: if variable initialization

Is this sarcastic? On 21 Mar 2018 12:58, "kai zhu" wrote: > this is why let and const should *never* have been introduced. if we had > stuck with just var, none of these petty-arguments and bickering among > team-members/shops on scoping-styles that ultimately have *zero*

Re: Proposal: if variable initialization

this is why let and const should *never* have been introduced. if we had stuck with just var, none of these petty-arguments and bickering among team-members/shops on scoping-styles that ultimately have *zero* productivity or benefit to web-projects would be possible. and there's nothing wrong

Re: Proposal: if variable initialization

``` if (someComplicatedCondition()) { doSomeLogic(); doSomeOtherLogic(if.value, true); } ``` On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo wrote: > Here are my gripes with `let` and `const` returning values: > > 1) declaration lists are hard to read: > > if ((let x =

Re: Proposal: if variable initialization

Here are my gripes with `let` and `const` returning values: 1) declaration lists are hard to read: if ((let x = 10, y = 20) > 15) { // true, but what's being compared here? 10 or 20? (answer: 20) } Although right now this is allowed and the last element is compared: if ((x

Re: Proposal: if variable initialization

OK I neglected to read the original post fully. My last post example would be based on allowing `const` and `let` declarations to expressions in of themselves (in the case of multi variables, returning the last one). So let me ask, what exactly would be the problem with this? On Wed, 21 Mar 2018

Re: Proposal: if variable initialization

What would `if.value` look like in an example? Wouldn't it be possible to have something like `if(const x = getX() && const y = getY())` to capture more than just the conditional if required? I'm guessing that would probably break something somewhere, but I'm not sure what. On Wed, 21 Mar 2018

Re: Proposal: if variable initialization

Is the use case only ever to capture the thing that serves as the conditional? If so, would perhaps something like `if.value` work better? Since it's a keyword, it could be made to only work in the `if` block, and you wouldn't need any of that odd multi-statement stuff in the conditional parens.

Proposal: if variable initialization

Proposal: inline let/const statements to declare and initialize variables within if statements, so that temporary variables exist only within the if/else block scope. Reason: limits variable scope to the block where really needed, in similar fashion to variables defined in for(;;) statements.