>> 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
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
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
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
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);
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
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
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
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
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`.
>
>
>
>
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.
--
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`.
--
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
13 matches
Mail list logo