偷偷告诉你我下一张身份证将会是永久有效的了

不要买 15 歀，必须 17 款，差别太大了

实在用不了 j8 还可以用 org.apache.common-collections 顶一下，别想可以有多大改进，只是换一种抽象（ functor 或说算子）而已

读一下 Thread.stop 为什么会是 deprecated, 这应该是基本知识

hashmap 设计回目的是为了性能而不是并发安全，你难道从来不看文档的吗

这不是显然的吗
现实中经济纠纷是私了效率高还是打官司效率高？

圈重点
「界面停留在系统选择界面,」

@sorra #13 重名的问题的确 error 比 warning 更合适, 不过有 lint 工具的话这个也不是什么大问题; 反而 mutable 变量不能在闭包中使用这一点我绝对认为 kotlin 的做法(当然只是 sugar) 更合理, 在没有更好选择的前提下为此写一个 wrapper 的做法简直就像破补丁一样太不优雅了

然而我只用 gg 登录

@SourceMan 2.3.7 才对

真能虾扯淡

@sorra 这根本是两个问题好吗，请看我给出的例子，这个问题和 it 变量没有关系，只是类型推断系统过于智能是否合适的问题而已

@twoyuan 很正常, type inference 有时候因为过于智能会显得比较魔幻

执行一下
fun main(args: Array<String>) = run { val run = 1; run { print("run: $run") } }

或者甚至 (后面这个会有个编译警告, 但警告的也仅仅是变量重名而不是 type inference 混淆)
fun main(args: Array<String>) {
val x: (() -> Any) -> Any = ::run;
x { val x = 1; x { print("x: $x") } }
}

i7 i8 我觉得裸奔都问题不大, 尤其是 i8 不能太舒服

至于 SE, 咳咳, 那个金属后背太容易磕碰刮伤了吧, 我以前一直都只是加个后背套套, 只是这个命运也是很难逃避得啦, 一图胜千言
http://wx4.sinaimg.cn/large/5257f553gy1fltl7w7ovxj20zk0zkq6y.jpg

既然没有亲情就讲法律好了
我猜这应该是一笔保险赔偿吧
那要看保险合同有没有写明确的受益人
如果没有的话这就是遗产，没有其它证据的前提下应该是唯二的继承者评分
我觉得你应该是不看重钱了只是咽不下这口气，那么为图省事期间，全部委托给律师打官司好了，大不了所有钱全给律师好了

async block 哪来的输入参数，明明是 ()->?

excited

另外，真心建议考虑一下 #8 的提议，能不能接受（主要是接口的减少，13 标准版是 4 个 USB-C，12 只有唯一一个，性能我觉得不是什么大问题）需要自己去实体店实际感受