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を期待しているのかなあと。

そうすると、 var x を通常の関数引数に渡す場合がどうなってるかは気になりますね

12:40 AM

可能性は2通り想定できて

12:41 AM

1. 渡す時に必要に応じてrvalueにcoerceしている 2. lvalueのまま渡しているが、特に問題が起きていない (edited)

12:41 AM

で、1の場合なのであれば、クラッシュするケースたちの場合もcoerceを足すのが正しいでしょう

12:42 AM

2の場合なのであれば、クラッシュするケースたちだけが rvalue assertion をしていることがおかしくて、そこは lvalue も許さないといけないでしょう

12:42 AM

要はassertionが間違ってるのか、それともassertionは正しくて準備不足がバグなのかのどっちかだということです (edited)

12:43 AM

(僕の勘では正解は 1のルートです) (edited)