Re: let-in if do-expr is problematic? (was: Re: proposal: let in if parentheses)

The “let bindings in expression” originates in mathematics and logic. I cannot speak for the original proposal but the major difference between this syntax is that it evaluates to an expression compared to the let statement which evaluates to undefined. One benefit of “let in” is that it is

Re: Function composition vs pipeline

I don’t know the implications but I could easily imagine the pipeline proposal being extended to not taking any input on the left hand side and effectively represent composition in the opposite direction. For example: ``` let h = |> f |> g h(2) //g(f(2)) ``` That said, the point holds for the

Re: Promise finally

Since these two Promises aren't chained to one another I wouldn't expect any specific deterministic ordering between the `console.log` statements. Are you suggesting that such a deterministic ordering should be imposed by using micro tasks or what are you proposing here exactly? In other words,

Re: an operator for ignoring any exceptions

I think this proposal has the risk of swallowing too many errors making code hard to debug and would therefore suggest this shouldn’t be added to the language. Silent errors are hard to find the origin and cause for especially if you throw away the error message. This might be slightly off topic

Re: Stage 0 Proposal: Extensible Collection Literal

One of the stated advantages of the proposal is that because it is syntax driven it allows for static error messages limiting some bugs. Using a method would not give the same degree of certainty of correctness as that would require assertions to be deferred to runtime, since EcmaScript is not

Re: Ranges

Even more interestingly what would `String.range("","zzz")` produce. From what code point is the range started? Will this throw? Is the empty string included in the iterator? 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>: > Actually, afte

Re: Ranges

ilar to for..of does it. > About `String.range("A", "zzz")`: Do any other possibilities even make > sense? > > On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote: > > For `String.range` what would the expected result of > > `String.range('A','zzz')

Re: Ranges

For `String.range` what would the expected result of `String.range('A','zzz')` be? Is an exhaustive pattern expected? `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]` 2016年11月3日(木) 19:21 Michael J. Ryan : > If there's a Number.range, if suggest a corresponding

Re: Proposal: anaphoric if and while syntax

Does this really need new semantic interpretation of the syntax? Using the `Array.prototype` methods `.forEach` and `.map` already mitigates this problem as far as I can tell by having a different bound variable (argument in this case) for each call. I agree that the behavior may be non-intuitive

Re: Map literal

airs. If the map type to which it's applied chooses to forget > the ordering then that's fine. > > Alex > > > On Wednesday, 28 October 2015, Viktor Kronvall <viktor.kronv...@gmail.com> > wrote: > >> > ``` >> > const map = IMap#{"foo&

Re: Map literal

> ``` > const map = IMap#{"foo": 42, bar: 44}; > ``` > It could desugar as, for the sake of example: > > ``` > Foo#{key: value, ...} > ➔ > Foo[Symbol.literalOf]([[key, value], ...][Symbol.iterator]()) > ``` I like this proposal. However, Maps should guarantee insertion order when traversing the

Re: Swift style syntax

> but I'd vote for `Math.greaterThan` I agree with this. This solution also disambiguates negate and minus which is good. If we were to introduce operators as functions with syntax I would prefer if there was some syntax to know if the operator was a binary or unary function. Regarding operators