rust最美建筑_如何看待 Rust 语言中新加入的 .await 后缀关键字？

大佬们怎么都没怎么回答啊, 弄得我都不敢回答了 (然而我还是回答了 (不过我要匿名

如何看待? 不喜欢 —— 和 .await(), .await!() 相比没有明显的好处, 虽然官方给出了解释但我不太认同.

首先, 官方基本认同应该采用后缀语法, 这点我也赞同.

然后 !@#$ %await() 对眼睛伤害太大了, 排除! 于是只剩 后缀关键字, 方法, 后缀宏 三种方案了

官方给出的不采用后两种方法的理由是:.await() 不是方法, 也没办法定义成方法, 而且会哪有改变控制流的方法

.await!() 无法用宏实现, 而且无法归类到目前已有的内置宏中(DSL or 打破"第四堵墙"的黑魔法)

然而 .await 也不是字段, 而且无类可归

官方也想到了这一点, 对此的解释是:句点运算符很普遍, 很容易建立心智模型 // 我没咋弄懂原文这句话的意思, 大概就是可以和字段, 方法调用"和谐"相处?

知道 await 语义的人不会把它当成字段的, 但采用后两方案只有了解 Rust 语义才会知道这玩意儿不可能是方法/宏

这玩意儿可以扩展为更普遍的"后缀关键字", 等效于某些前缀关键字 (如 match) 的后缀版本.

第一点我认为对于后缀宏也适用, .await() 在这里倒确实有点奇怪——因为太容易理解成方法调用了, 我寻思着肯定会有人试图取它的地址, 而且改变控制流的方法也太魔幻, 所以踢掉 (

第二点有点道理, 毕竟没人会相信对一个字段的访问会改变控制流. 不过反正都要在教程里特地提一句, 这个造成的影响我觉得有限.

第三点看起来好像很美好, 但是!! 后缀宏带来的可能性比这玩意儿多多了好吗!! 而且你说了会引入前置 await 对吧? 你说了对吧! 那这个时候不就可以用宏来实现 await 了吗!?

[接下来是后缀宏吹]

我个人是支持后缀宏的, 因为后缀宏实在是 太! 强! 了! 我觉得大多数支持后缀宏的人应该都是冲着"后缀宏"而不是"后缀宏语法的 await"去的.

首先, macro 2.0 实现以后, 函数与宏会非常相似, 这个时候后缀宏就会变得非常自然 —— foo.bar() => bar(&foo), foo.bar!() => bar!(foo), 和 macro 2.0 相得益彰!

其次后缀宏包容性非常强, 所谓"后缀关键字"可以用后缀宏轻松实现, 而且灵活性更强!

// 不需要前后加括号就可以方便地链式调用foo().match!({}).await!()// 换后缀关键字的话就得这样, 长一点就会很难看(foo().match{}).await

选择后缀宏方案, 可以先临时开洞把 await! 当成内置宏(反正你后缀关键字也是先开洞就别五十步笑百步了), 然后后缀宏实现以后, 就可以引入前缀关键字 await, 然后就可以用后缀宏实现 await 了! 如果后缀宏早点实现我们可以甚至不需要 ?, .try!()就行了. (当然 ? 这么甜肯定是要的

太强了好吗!! awsl, 后缀宏赛高!

我永远喜欢后缀宏.webp

(感觉希望也不大了, 毕竟后缀宏一实现, 所谓 "后缀关键字" 就没啥意义了. 官方不可能想不到这一点, 除非......

更:

评论区提到当前有个问题就是即使是宏定义也是不允许使用关键字的...

这确实是个问题, .r#await!() 很丑, 如果靠开洞的话又违背了我支持后缀宏的初衷, 我能想到的解决方案要么是对宏放开这个限制, 要么是换名字(比如 awaited)......哪个好像都不怎么优雅......

不过往好处想这样一来即使引入了后缀宏也不会完全抹杀掉后缀关键字存在的意义, 那引入后缀宏还是有希望的!