Re: try/catch/else

>> On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache >> wrote: >>> >>> What about the following pattern (labelled block + break)? >>> >>> ```js >>> processSuggestions: { >>> let suggestions; >>> try { >>> suggestions = await fetchSuggestions(); >>> } catch

Re: try/catch/else

I honestly wish engines (read: V8) didn't jave so much issue optimizing that. But yes, it's a very useful pattern. On Thu, Feb 8, 2018, 14:35 Mark Miller wrote: > Hi Claude, that's nice. Whenever I faced this issue I always turned to the > boolean flag variable. But this is

Re: try/catch/else

Hi Claude, that's nice. Whenever I faced this issue I always turned to the boolean flag variable. But this is strictly better. I expect to use it from now on. Thanks! On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache wrote: > What about the following pattern (labelled block

Re: Suggestion: Infix operators/functions

Time to put infix operators into TypeScript, first, then? On Sat, 3 Feb 2018 at 04:25, kdex wrote: > People in the C++ community have been using overloaded operators since the > 1980's, and I wouldn't say that different semantics for the same operator > have > been a bad idea at

Re: try/catch/else

What about the following pattern (labelled block + break)? ```js processSuggestions: { let suggestions; try { suggestions = await fetchSuggestions(); } catch (e) { alert('Failed to load suggestions'); break processSuggestions; } showSuggestions(suggestions);

Re: try/catch/else

Sounds good in principle but I think the name is misleading. Actually try/catch/else is the synchronous equivalent of tryFn().then(elseFn, catchFn) but then has other implications (it returns a new promise and the then method actually takes two functions). Calling it then would imply it's

Re: try/catch/else

Well, since promise.then(/**blah**/).catch(/**blah**/) is already a thing, why not stick with that? try { // blah } then(val) { // blah } catch { // blah } finally { // blah } I added `val` to the then since we might want to pass something from `try` to it, just as promises do. Best way to

try/catch/else

Hi everyone, I'm hoping this is the right medium to ask this but I would like to propose a language feature called try/catch/else. Conditional try/catch seems to be all the rage right now but in many cases the problem it really wants to solve seems to be code like the following: try { const

Re: Suggestion: Destructuring object initializer.

It does make one stop and wonder why the group will endlessly entertain trolls debating whether or not ES6 (or ES5) portends the end of civilization as we know it, while relentlessly ignoring literally dozens of similar/identical proposals for property picking, a feature which easily contributes

Re: Suggestion: a chainable in-place alternative of `Array.prototype.map`.

Already discussed (at the end there's an Array.prototype.each idea that's the same): https://esdiscuss.org/topic/return-value-of-foreach On Thu, 8 Feb 2018 at 14:17 Yeong-u Kim wrote: > # Suggestion: a chainable in-place alternative of `Array.prototype.map`. > > > >

Re: Suggestion: Destructuring object initializer.

This extremely useful feature, which is sometimes called "picking", has been discussed extensively on the group, but the "thought leaders" (?) who apparently have the ability to kill a feature by saying "I don't really think it's that important" have failed to get excited about it, although it

Suggestion: Destructuring object initializer.

# Suggestion: Destructuring object initializer. -- Destructuring assignment: it extracts values by destructuring an object, and assign _them_ to ‘variables.’ I suggest Destructuring object initialization syntax; it is similar to Destructuring assignment, except that it initializes an

Suggestion: a chainable in-place alternative of `Array.prototype.map`.

# Suggestion: a chainable in-place alternative of `Array.prototype.map`. -- I personally do make massive use of `Array.prototype.map` whenever I code in ECMAScript. However, it often leaves an array waiting for garbage collection (which makes unnecessary memory use and burdens the