# What does the new "public" keyword actually do?
**URL:** https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975
**Category:** General Usage
**Tags:** question
**Created:** [January 18, 2024, 5:25pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975 "2024-01-18T17:25:34Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [January 18, 2024, 5:25pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/1 "2024-01-18T17:25:34Z")
Continuing from
> [@New Julia LTS? Are many using the current (Julia 1.6) LTS?](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/54):
>
> Do you think “public” will actually not be used much in packages as opposed to Julia itself (since there it’s problematic to export)?
> [@New Julia LTS? Are many using the current (Julia 1.6) LTS?](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/57):
>
> It seems the new possible 1.10 LTS (assuming `public` not added) will be dead-on-arrival, with people not wanting to use it.
Does the new `public` keyword actually do anything? From the current 1.11 documentation and release notes, I don’t see that `public` has any effect on `using`/`import`.
It seems that maybe `Documenter` would be the primary consumer of the `public` information: I could see docstrings for public/private members being formatted differently, or `@autodocs` being able to filter on `public/private/exported`. I don’t think there’s a PR branch yet in Documenter to add those features, though.
Without that, it seems like `public` would really only surface when inspecting the source code of a package.
This is not to criticize the new feature. I very much like the idea of marking members as public non-public independently of other conventions such as underscore prefixes or hidden documentation. But it would seem to be relevant for how urgently one would want to adopt this feature and drop pre-1.11 support in packages. If there has to be slow-growing adoption by Documenter or similar tools (VSCode, I’d imagine) _after_ the 1.11 release, this does not seem as pressing.
So what are the plans for any downstream effects of `public`?
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [January 18, 2024, 5:43pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/2 "2024-01-18T17:43:33Z")
I’d appreciate the reflection, in other words I can identify public or internal names with function calls instead of searching or reading the much longer documentation. It’s also quicker to identify public names in my own code this way than it is to write out documentation, when I’m likely at a stage where I’m not certain what to write down.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [January 18, 2024, 6:14pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/3 "2024-01-18T18:14:10Z")
> [@goerz](#):
>
> Does the new `public` keyword actually do anything? From the current 1.11 documentation and release notes, I don’t see that `public` has any effect on `using`/`import`.
It affects `names(module)`, which now includes by default identifiers that are non-exported but marked `public`.
So, basically, it gives an automated way to list the API of a module that is intended to be documented and non-private, whether or not it is exported into your namespace by `using`.
There is also a new `Docs.undocumented_names(module)` function that can be used in testing to check whether there are any names that are “public” (including exported symbols) that don’t have a docstring, i.e. with `@test isempty(Docs.undocumented_names(MyModule))`.
(In the future, one could imagine QA tools that check whether a package uses any non-public symbols from another package.)
---
### Author:  [@jishnub](https://discourse.julialang.org/u/jishnub)
#### Post date: [January 18, 2024, 6:21pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/4 "2024-01-18T18:21:35Z")
One of the potential impacts of `public` that I’ve heard mentioned is on new packages that are being registered. If they are accessing private names from their dependencies, they may need to compat-limit these to specific minor versions. This includes minor releases of Julia. This will hopefully ensure fewer breakages, as only packages that are using public APIs will be allowed to upgrade to new versions.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [January 18, 2024, 6:37pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/5 "2024-01-18T18:37:53Z")
> [@jishnub](#):
>
> If they are accessing private names from their dependencies, they may need to compat-limit these to specific minor versions. This includes minor releases of Julia.
Could be nice in the ideal world, but so many packages use stuff like `Core.Compiler.return_type` that putting these restrictions is probably infeasible for now.
---
### Author:  [@gdalle](https://discourse.julialang.org/u/gdalle)
#### Post date: [January 19, 2024, 8:08am UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/6 "2024-01-19T08:08:16Z")
> [@stevengj](#):
>
> (In the future, one could imagine QA tools that check whether a package uses any non-public symbols from another package.)
>
>
> See \[this comment on Discourse\](https://discourse.julialang.org/t/what-does-the-…new-public-keyword-actually-do/108975/3):
>
> \> In the future, one could imagine QA tools that check whether a package uses any non-public symbols from another package.
>
> Sounds like a job for Aqua? Not urgent of course but opening the issue to keep track
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [January 19, 2024, 2:18pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/7 "2024-01-19T14:18:31Z")
This sounds like a cool feature but honestly is not the groundbreaking thing that the LTS thread makes it sound like, in my opinion. Thanks for starting this thread and asking the question.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [January 19, 2024, 8:05pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/8 "2024-01-19T20:05:04Z")
Yes, the responses here pretty much confirm my suspicion. The [new `names` behavior](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/3) is not nothing, but the real benefit of `public` is to put the ecosystem on a long-term path for better tooling. That tooling will take a while to develop after 1.11 is released.
Thus, making 1.10 the next LTS (without `public`) seems like the right call. Especially because `@compat public` is more than a viable solution for the current (next) LTS release cycle.
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [April 14, 2024, 9:56pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/9 "2024-04-14T21:56:52Z")
> [@goerz](#):
>
> `@compat public` is more than a viable solution
Compat.jl is a rather large dependency for a no-op. Here an alternative solution:
```julia
@static if VERSION ≥ v"1.11"
# therein declare public identifiers
include("public.jl")
end
```
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [April 14, 2024, 10:17pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/10 "2024-04-14T22:17:27Z")
There is [GitHub - JuliaLang/Public.jl](https://github.com/JuliaLang/Public.jl) if you want a smaller dependency.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [April 14, 2024, 10:40pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/11 "2024-04-14T22:40:00Z")
> [@mkitti](#):
>
> There is [GitHub - JuliaLang/Public.jl](https://github.com/JuliaLang/Public.jl)
Unless I missed some recent activity: there was considerable pushback against that package at the time, and it never ended up being registered
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 14, 2024, 11:48pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/12 "2024-04-14T23:48:39Z")
> [@Eben60](#):
>
> [Compat.jl](https://juliahub.com/ui/Packages/General/Compat) is a rather large dependency for a no-op. Here an alternative solution:
It’s probably installed anyway on your machine, since so many packages use it. And as a runtime dependency it should be quite small — most of it is precompiled away if you have a recent Julia version.
---
### Author:  [@Lilith](https://discourse.julialang.org/u/Lilith)
#### Post date: [July 23, 2024, 3:18pm UTC](https://discourse.julialang.org/t/what-does-the-new-public-keyword-actually-do/108975/13 "2024-07-23T15:18:25Z")
In addition to the above, when you query the docstring of a private method in the REPL, you get an informational warning.