会啊，Kotlin 是 call-by-value 的，也就是即时求值，调用参数在控制权交给子程序之前求值。
……等等，那是指调用实际发生的时候
你试下就可以了：

val xs: MutableList<Unit>? = null
xs?.add(println("emmm"))

答案是不会，对 MutableList.add 的调用没有实际发生，所以它的参数没有被求值，也就没有导致 println 副作用生效。

也不是特别困难啊，咱实现的时候直接空跳转就可以了，if expression 也可以。

Kotlin 的设计者比本苏厉害得多，相信他们的选择有合理性，只是咱暂时没法理解。

什么问题，求值不一定发生造成不一致？

这里本苏用几个术语，相信大家能理解，就是 eval 嘛。

不对啊，不应该那样

del 是动词还是 predicate

assert 不应该被这样使用的

release 是什么意思，exception thro n?

不是应该用 try ith resource 嘛？

这种脑残程序员应该拉出去续 200s

所以说它不该被滥用

Kotlin 提供了 check, require 和直接 error
assert 只有 jvm 提供了，这就造成不一致性
而且 assert 的居然还不是接受 block！这一点咱不喜欢。

其实 assert 这个东西只能算是一种甜点上的糖霜，也没啥大不了的，差不多是运行时的「条件编译」。
Java 1.4 就加上了，很可惜 Kotlin 居然也继承了它这个……

其实 pomodoro 不是特别难开发，只是有几个状态。

beginWork, pausedBreak, beginBreak
initial beginWork

1. beginWork -> beginBreak
2. beginBreak -> pausedBreak
3. pausedBreak -> pausedBreak
4. beginBreak -> beginWork

每个状态的转移都有信号：

(1) 可以提示『休息一下吧』
(2)、(3) 可以提示『休息已被中断』
(4) 可以提示『请恢复您的工作』

每个状态转移都是由定时或者外部信号导致的：

1. 定时『下次休息』超时
2. 3. 光标焦点移动、击键什么的
4. 定时器『休息时间』超时

此外，

beginWork 就要设置定时器『下次休息』为『下个休息时长』
beginBreak 就要设置定时器『休息时间』为『下个休息时间』

这是我们的基本抽象，可以做成 daemon。

然后是『下次休息』和『休息时长』，我们说的是「下个」，这就是说休息时长是一个序列。

可选 微休，每隔 time 休息 time
建议时间 6min : 30sec
可选 全休，每隔 time 休息 time
建议时间 40min : 6min

定时器的使用上就随便用吧，几个时间可以一起定，但状态转移都在 (1) 或 (4)
在第一个定时器响铃时，就必须撤销所有其他定时器了。

正在重构 Qt 官方的一个示例，顺便学习一点音频信号生成和 C++ Qt 开发。

这个等式就应该重构，为什么我们不先算每个 channel 的 byte length，再求总共的积？那样不是更符合正常思路吗？

void repeat(unsigned n, void(*op)(unsigned) ) {
for (unsigned i=0; i<n; i++) op(i);
}

不喜欢 C++

我数学不好，但还是了解了音频的 format、int channel、sample rate、sample size 什么的

不愧是 C++ 呢，各种 const noexcept override 让人感觉莫名其妙，stl 各种可以用的烂代码，保持傲慢与偏见，我从来不写没有用的代码，一个字符也不。
一个字符都不多写，刚刚好够用、明确就足够，C++ 新建抽象太麻烦，根本比不上 Kotlin 的安逸。
不是像大部分人，一个字符的解释也不多给、一条使用模型总结也不弄，只有自己写出来了就足够，也是刚刚好。

STL，是是，设计和算法非常好，但就是代码风格不能让正常人看，我不知道 _M_name 对人类可读性来说有什么好的，看起来什么东西都往一个文件放，不加任何解释和 brief，很 UNIX。

我都不知道同时弄什么客户 header 啊、实现啊，它给逻辑抽提制造的麻烦与那一点点『实现无关性』『简洁性』相比是熟轻熟重，看起来好像 header 和 preprocessor 这两个不得了的东西比程序员对代码维护的便利性还重要，C++ 就是不让你重构的，一开始就想好了嘛。