I would like to understand Julia’s rationale for not including a language-level privacy feature: a way to truly protect the internal state from outside access. I’m aware that we can use closures to emulate encapsulation, but that’s cumbersome, and it’s not really the same as a built-in mechanism. I’ve often heard the “We’re All Adults Here” mindset mentioned, but I find that unconvincing; even experienced developers introduce critical bugs—memory-safety issues in C/C++ being just one high-profile example. Of course, Julia’s garbage collection helps prevent memory corruption, but direct messing with internal structs can still lead to logical or invariant-breaking bugs. So, is there a deeper reason why Julia can’t (or shouldn’t) offer an opt-in privacy model? I’d personally find it fair if those who want stricter encapsulation “pay” with potential performance or debugging complexity. But I’d love to hear the community’s thoughts on whether this is feasible or if it conflicts too deeply with Julia’s design goals around metaprogramming and introspection.

I found this weird, too, at the beginning. Now I believe: the Julia status quo is preferable to what the stricter, “object-oriented”, languages have the status quo will improve further The benefits exist for interactive usage, e.g., in exploration in the REPL, also testing, in some cases. This is huge and I don’t think any experienced user is willing to give it up. The drawback is packages being able to trespass on the internals of the Julia implementation, or the internals of other packages, leading to breakage on a new release of such an intruded-on dependency. IMO the problem isn’t being able to poke at internals of dependencies on its own, the problem is being able to do that while failing to pin the version of that dependency properly in Project.toml. So I expect this will be solved in a best-of-both worlds manner; now that we have public and Base.ispublic, the required validation can happen programmatically. It’s possible to: have a check disallowing the registration of package release have a check for an editor linter implement an actual strict check as part of a strict mode for Julia: Add `strict` mechanism for opting into stricter subsets of the language · Issue #54903 · JuliaLang/julia · GitHub None of this is implemented, yet, though, AFAIK. Another relevant issue is Disallow access to internals (unless overridden) · Issue #52314 · JuliaLang/julia · GitHub

It’s not only structs, but also functions/methods. Nothing prevents you from making e.g. Int an iterator to iterate through the numbers below (if one believes in the von Neumann definition of the natural numbers): function Base.iterate(n::Int, state=nothing) isnothing(state) && return n collect(5) 5-element Vector{Int64}: 0 1 2 3 4 However, a lot of things will be messed up by this fancy trick, since they may rely on the default behaviour, that collect(5) returns a 0-dimensional Array containing 5. The same goes for every method in every package. Anyone can replace any method. There is work underway to make it possible to “freeze” functions so that methods can’t be overwritten or added.

This feature and a way to describe an API and force it on the implementation is the two language features I miss the most. Edit: I am not considering small binaries / AOT / creation of libraries a language feature :smiley:

[image] younes: I’m aware that we can use closures to emulate encapsulation, Hopefully you are aware that closures provide only marginally more privacy than structs, e.g.: julia> f(a) = () -> a f (generic function with 1 method) julia> b = f([55,77]) #3 (generic function with 1 method) julia> b() 2-element Vector{Int64}: 55 77 julia> b.a[1]=0 0 julia> b() 2-element Vector{Int64}: 0 77 but AFAIK, this behaviour is undocumented and could change in future versions.

[image] younes: direct messing with internal structs can still lead to logical or invariant-breaking bugs It also lets you extend behavior without waiting for the public API to allow it, and it’s often not a reasonable expectation for the public API to irreversibly support something that you may not want for long. This is how third party libraries can pull off static type inference or compiler plugins in a typical Julia process. But as you said, this is exceptional; for the most part we are heavily incentivized to not rely on things that can break on minor releases, hence the strong encouragement of documentation, leaning toward documenting methods instead of fields, and more recently a formal specifier of public global names (so not public fields, or rather properties). The more common usage of internals is interactive reflection without needing to write extra API from a reflection library or resort to undefined behavior. Historically, the “who needs access modifiers, we’re all adults” philosophy is standard in popular, interactive-first, dynamically typed languages preceding Julia e.g. Smalltalk, MATLAB, Python, R. Julia also cannot share the access modification of OOP languages that have class encapsulation; we can’t nest private types in other types. If we couldn’t access types with non-public global names, they’d be useless. While it’s not true access modification, you can also make it harder for people to access fields by overloading getproperty and, for mutables, setproperty!. That forces them to resort to getfield/setfield! instead of using dot syntax.

There’s propertynames for marking a property as public. It defaults to making all fields be public properties, sadly.

Good catch, I think you’re refering to propertynames though. Does that mean hasproperty can be used for validation like ispublic?

I don’t think you can “truly” protect internal state from outside access in a compiled language. You can always convert to a Ptr and access/modify data manually. So privacy is a question of programming convenience, not of actual safety. So with that in mind: the benefits of a strict enforcement at compile time versus just telling users “don’t do this” is marginal. In my own code I violate the “don’t do this” all the time: sometimes I need an internal function and I just don’t want to take the time to copy-and-paste it, or I worry that any improvements in future versions will be missed out. This does make my packages somewhat brittle, which is not great, but CI in Julia is very effective at catching bugs that result from this.

[image] dlfivefifty: This does make my packages somewhat brittle I am having trouble right now with wrapping a C++ library where too much of attributes are made private. As you have said, it’s possible to circumvent that by taking raw pointers etc. and it would be much more brittle than in Julia, I think. So, I’d say the contrary is true: if you end up needing to break the rules, with C++ approach it’ll be inherently brittle (dependent on platform, compiler conventions etc.) while with “don’t do this” approach it may be done reasonably robust.

[image] Benny: Does that mean hasproperty can be used for validation like ispublic? Not in practice, at least not in general. All fields are declared as public properties by default, and it’s actually kinda rare to define a propertynamesmethod for one’s type, so hasproperty will usually answer true even if the property isn’t supposed to be public :confused:

Why doesn’t Julia offer built-in privacy/encapsulation features?

General Usage

stevengj January 11, 2025, 5:10pm 10

@StefanKarpinski’s post in a related thread may give some insight into the underlying philosophy: Private states in Julia modules - #19 by StefanKarpinski

Topic		Replies	Views
Private states in Julia modules General Usage question , package	24	8222	November 20, 2024
Mutable struct vs closure New to Julia struct , closure	74	6651	February 1, 2019
Base.modules_warned_for silently removed in 1.8 General Usage breaking	133	6623	June 16, 2022
Implementation Hiding Proposal Internals & Design proposal	19	2053	May 10, 2018
Accessing type internal fields in package interfaces General Usage question	14	1856	October 28, 2021

Why doesn’t Julia offer built-in privacy/encapsulation features?

Related topics