TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Rust Traits Deep Dive, Part 2

144 点作者 chriskrycho将近 7 年前

3 条评论

Animats将近 7 年前
The text, with examples, is here.[1] Read that, skip the audio.<p>About operators, he writes &quot;So, to grab one of those earlier examples: when you write a + b, that&#x27;s equivalent to calling a.add(b) or b.add(a) or even Add::add(a, b). The operator is special syntactical sugar for the trait.&quot; But <i>which one</i> of those?<p>This matters, because it leads to mixed-mode semantics trouble. Who determines the output type of &quot;a + b&quot;? &quot;a&quot;? &quot;b&quot;? Both? Are there implicit type conversions? This is where C++ gets into strange interactions between type converters and generic selection. C++ resolves this with a rule that, when there are multiple possible instantiations, the selected one must be one notch &quot;better&quot; than the alternatives.<p>Python gets into mixed-mode trouble with numpy arrays vs. built-in lists. In Python, &quot;[2,4] * 2&quot; is [2,4,2,4], while &quot;array(2,4) * 2&quot; is [4,8].<p>It&#x27;s a classic problem in language design. If there are no implicit conversions, users complain about having to write &quot;1.0&quot; instead of &quot;1&quot;, or worse, having to write &quot;1.0L&quot;. If there are too many implicit conversions, you get unexpected semantics. Basically, conversions are there for numbers. Then somebody decides to generalize them. That sometimes ends badly.<p>There&#x27;s nothing here about what Rust does about conversions, but that may be covered in one of the other many parts of this series.<p>The good news is that the Rust programming book is finally coming out in just 6 more days. So there&#x27;s something better to read than this.<p>[1] <a href="https:&#x2F;&#x2F;newrustacean.com&#x2F;show_notes&#x2F;e024&#x2F;struct.script" rel="nofollow">https:&#x2F;&#x2F;newrustacean.com&#x2F;show_notes&#x2F;e024&#x2F;struct.script</a>
评论 #17354921 未加载
评论 #17353471 未加载
评论 #17354720 未加载
评论 #17355293 未加载
评论 #17356940 未加载
评论 #17354289 未加载
评论 #17355397 未加载
评论 #17356542 未加载
评论 #17360664 未加载
评论 #17354093 未加载
评论 #17355439 未加载
toyg将近 7 年前
I&#x27;ve just started working with Rust, coming from a python&#x2F;java&#x2F;web background. Some of the constraints are a bit mind-bending, and the ecosystem is very immature; but compared to C&#x2F;C++, it&#x27;s a dream.<p>It only needs a few things to achieve world domination, imho: a good crossplatform GUI toolkit, and a trivial way to interface with higher-level languages like Python.
评论 #17356215 未加载
评论 #17355201 未加载
eslaught将近 7 年前
In this example:<p><pre><code> fn collect&lt;B: FromIterator&lt;Self::Item&gt;&gt;(self) -&gt; B where Self:Sized; </code></pre> I thought this was universal, not existential like the podcast claims. It would be existential if you instead wrote:<p><pre><code> fn collect(self) -&gt; impl FromIterator&lt;Self::Item&gt; where Self:Sized; </code></pre> The latter is what got added in 1.26, whereas the former was already available before that.<p>And really, you wouldn&#x27;t want to use the latter in this case because the user wants to choose the type that&#x27;s being generated (this is not a case where you want the callee to choose the type). So the second signature wouldn&#x27;t make a whole lot of sense even if this API had been stabilized post-1.26.
评论 #17366400 未加载