shiz

transferringからリネームされたのは、それが結局オーナーシップとしてはどれになるのか、の観点で、結局consumingであるという方が重要ということかなと

はい、僕も調べてみてそう思いました。

それがimplicit consumingならわかるんですが、そこにcopyableが挟まってるのがちょっと謎ですが

これはconsumingが「implies no implicit copy semantics」なのでそれとは違うことを明示したかったのかなと思っています。

↑これでもクラッシュすることを見つけました

なるほど！sendingではなく、そもそもLValueであることが問題なのですね...

そうなってくると、rvalueを要求してる場所にlvalueを渡してるのがバグで、rvalueにcoerceするのが正解ってだけなんじゃないか・・・？

だんだんそうなのではという思いが強くなってきました。 SILGenの段階でも

RValue RValueEmitter::visitMakeTemporarilyEscapableExpr( MakeTemporarilyEscapableExpr *E, SGFContext C) { // Emit the non-escaping function value. auto functionValue = visit(E->getNonescapingClosureValue()).getAsSingleValue(SGF, E);

なので、RValueを期待しているのかなあと。

consumingが「implies no implicit copy semantics」なのでそれとは違う

ああ、なるほど。mutabilityとは別に、コピー解析の時の振る舞いにも影響するからそれをまとめてるのか。