Jack Works

Extra benefit: Once we have the concept of `ExprBlock`, we can use it in both the pattern matching proposals (without considering if we need a `do` keyword or not) and...

> Pattern matching relies on do expressions for the RHS of a match clause, and to be able to put a statement list there. This alternative proposal wouldn’t meet that...

> The most useful feature of do expressions is "turning a statement list into an expression", which this alternative does not do. "Turning a statement list into an expression" is...

> Almost every single statement would need to be made into an expression That really isn't much. - BlockStatement => Expr Block `expr { ... }` - IfStatement => `if`...

And don't you think splitting them make them much more composable? You can use the necessary syntax without the extra `do {}` when it doesn't contain Declarations. ```js const a...

I thought about this case, it's awkward: ```js const val = expr { if (val2) console.warn('what') // syntax error, expected token "else" val2 + 1 } ``` > I think...

I'll try to measure how this proposal improves the language when handling a set of Promises. - Negative impact, withdraw this proposal. - Little positive impact, ask for the implementors....

> Thank you for taking the time to open this issue and suggest fixes to the problem. I kindly ask that you consider creating a pull request with your suggested...

> For places like IOT they do not have any parser so we at minimum need to avoid requiring bringing the source code in a JS API Disabling source code...

如果没有温度传感器，可以通过 current_temp_property 使用空调的目标温度作为显示的温度，例： ```yaml customizing_device: lumi.acpartner.mcn02: sensor_attributes: electric_power,power_cost_today,power_cost_month current_temp_property: target_temperature ```