公有成员与私有成员之间的中间可见性

Lobsters Hottest 新闻
rust language-design structs access-control encapsulation discussion

摘要

一场关于 Rust（或未来语言）是否应该为结构体字段添加 `read` 可见性修饰符的 Lobsters 讨论：允许对外提供只读访问而不可写，并询问是否存在隐藏的语言设计陷阱以及合理的默认行为。

<p>假设我有这样一个结构体</p> <p><code>struct Foo { pub public: Bar, restricted: Qux }</code></p> <p>其中 ‘restricted’ 是一个成员变量，我希望在结构体方法之外能够读取它，但不能修改它。通常我会写一个 getter 方法</p> <p><code>impl Foo { pub fn restricted(&amp;self) -&gt; &amp;Qux { self.restricted }}</code></p> <p>这并不需要写多少代码，而且我可能可以通过 IDE 或插件自动生成这些方法。</p> <p>但话说回来，为什么不把这一点直接内置到声明语法中呢？在 <code>private</code>（在 Rust 中是隐式的，但有些语言是显式的）和 <code>public</code> 之间加一个修饰符。比如用 <code>read</code>，这样我们就能写成</p> <p><code>struct Foo { x, read y, pub z }</code></p> <p>其中 x 对结构体而言是真正的私有成员，只有成员函数才能读写；y 任何人都可以读取，但不能随意修改；z 任何人都可以读写？</p> <p>这需要区分对 foo.y 的访问和修改（访问 vs 可变），这可能并不简单，但看起来也并非特别困难。</p> <p>我很好奇这里是否存在隐藏的陷阱，使其从语言设计的角度来看复杂得多，或者不如我预想的那样符合人体工程学。如果没有的话，这似乎是未来语言可以实现的一个直接特性，我认为值得为它增加一个关键字。</p> <p>而且，如果这是可行且可取的，那么默认行为应该是什么？如果三种状态都存在的话，将只读作为默认值似乎比完全私有更合理一些。</p> <p>期待听到大家的想法。</p>
查看原文
查看缓存全文

缓存时间: 2026/10/20 08:10

# 公共成员与私有成员之间的中间状态 来源：https://lobste.rs/s/fonp7g/intermediary_between_public_private 假设我有这样一个结构体： ```rust struct Foo { pub public: Bar, restricted: Qux } ``` 其中 `restricted` 是一个成员变量，我希望能从结构体方法外部读取它，但不能修改它。通常我会写一个 getter 方法： ```rust impl Foo { pub fn restricted(&self) -> &Qux { self.restricted }} ``` 这需要写不少代码，而且大概可以用 IDE 或插件自动生成。 但话又说回来，为什么不把这个功能直接内置到声明语法中呢？在 `private`（Rust 中是隐式的，但有些语言有这个关键字）和 `public` 之间加一个修饰符，比如 `read`，这样我们就可以写成： ```rust struct Foo { x, read y, pub z } ``` 其中 x 是真正的私有成员，只能被成员函数读写；y 可以被任何人读取，但不能随意修改；z 则可以被任何人读写。 这需要区分对 `foo.y` 的访问（access）和修改（mutation），可能并不简单，但看起来也不是特别复杂。 我想知道这里是否存在某些隐藏的坑，会让它从语言设计角度变得复杂得多，或者用起来不如我设想的那么顺手。如果没有的话，这似乎就是未来语言可以实现的一个很直接的特性，我认为值得为它增加一个关键字。 如果这是可行且理想的，那么默认值应该是什么？如果三种状态都存在的话，把只读作为默认值，似乎比完全私有更合理一些。 很想听听大家的想法。

相似文章

Bun 的问题可能在于公开开发

Lobsters Hottest

一篇分析 Bun 实验性使用 LLM 将其 Zig 代码库转译到 Rust 所引发的争议的文章，强调公众的强烈反应源于透明的开发实践而非实验本身。

限制 trait 的可实现性与字段可变性

Lobsters Hottest

Rust 宣布对 RFC 3323 功能进行 nightly 测试，这些功能限制 trait 的可实现性和字段可变性，为密封 trait 模式和 getter 方法提供了直接替代方案。

rust-lang/rust 正在采用 LLM 政策

Hacker News Top

Rust 项目正在采用一项新政策，规范在向 rust-lang/rust 单一代码库贡献时如何使用 LLM，为 PR 作者、审查者和问题报告者制定正式规则。