Intermediary between public and private members

Lobsters Hottest News

Summary

A Lobsters discussion exploring whether Rust (or future languages) should add a `read` visibility modifier for struct fields, allowing public read access without public write access, and asking about hidden language-design gotchas and sensible defaults.

<p>Say I were to have a</p> <p><code>struct Foo { pub public: Bar, restricted: Qux }</code></p> <p>where ‘restricted’ is some member variable which I want to be able to get, but not set, from outside of the struct methods. Normally, I would write a getter method</p> <p><code>impl Foo { pub fn restricted(&amp;self) -&gt; &amp;Qux { self.restricted }}</code></p> <p>which isn’t very much typing, and probably I could generate these automatically with an IDE or a plugin.</p> <p>But all the same, why not build this into the declaration syntax with a modifier in between <code>private</code> (implicit in Rust but some languages have it) and <code>public</code>? Maybe something like <code>read</code> so that we could have</p> <p><code>struct Foo { x, read y, pub z }</code></p> <p>Where x is genuinely private to the struct and can only be read or written by member functions, y can be read by anyone but not modified arbitrarily, and z can be read or written to by anyone?</p> <p>This would need to distinguish between access and mutation of foo.y, which may not be trivial but doesn’t seem outwardly especially difficult.</p> <p>I’m wondering if there are hidden gotchas here that make this a lot more complex from a language design perspective, or less ergonomic than I’m assuming. If not, it seems like a straightforward feature for future languages to implement, worth an extra keyword, I would think.</p> <p>And if it it possible and desirable, what should the default be? It makes some sense to be that read-only is a more sensible default than full privacy if all three states are available.</p> <p>Eager to hear people’s thoughts.</p>
Original Article
View Cached Full Text

Cached at: 10/20/26, 08:10 AM

# Intermediary between public and private members Source: [https://lobste.rs/s/fonp7g/intermediary_between_public_private](https://lobste.rs/s/fonp7g/intermediary_between_public_private) Say I were to have a `struct Foo \{ pub public: Bar, restricted: Qux \}` where ‘restricted’ is some member variable which I want to be able to get, but not set, from outside of the struct methods\. Normally, I would write a getter method `impl Foo \{ pub fn restricted\(&self\) \-\> &Qux \{ self\.restricted \}\}` which isn’t very much typing, and probably I could generate these automatically with an IDE or a plugin\. But all the same, why not build this into the declaration syntax with a modifier in between`private`\(implicit in Rust but some languages have it\) and`public`? Maybe something like`read`so that we could have `struct Foo \{ x, read y, pub z \}` Where x is genuinely private to the struct and can only be read or written by member functions, y can be read by anyone but not modified arbitrarily, and z can be read or written to by anyone? This would need to distinguish between access and mutation of foo\.y, which may not be trivial but doesn’t seem outwardly especially difficult\. I’m wondering if there are hidden gotchas here that make this a lot more complex from a language design perspective, or less ergonomic than I’m assuming\. If not, it seems like a straightforward feature for future languages to implement, worth an extra keyword, I would think\. And if it it possible and desirable, what should the default be? It makes some sense to be that read\-only is a more sensible default than full privacy if all three states are available\. Eager to hear people’s thoughts\.

Similar Articles

Bun's problem may be developing in the open

Lobsters Hottest

An article analyzing the controversy around Bun's experimental use of an LLM to transpile its Zig codebase to Rust, emphasizing that the public uproar stemmed from transparent development practices rather than the experiment itself.

Rust-lang/rust is adopting an LLM policy

Hacker News Top

The Rust project is adopting a new policy governing how LLMs can be used when contributing to the rust-lang/rust monorepo, formalizing rules for PR authors, reviewers, and issue reporters.