Unexported functions

Why if I have a module like this:

module Demo

suma(a) = a + 1


I can access it through Demo.suma(123), if it has not been exported, should not be exported first to be accessed?

No, export only affects what you get when you using. You might find https://docs.julialang.org/en/v1/manual/modules/#Summary-of-module-usage-1 useful.


So there is no way to make something private to the module?

If I understand right, I think Julia takes the Python approach to visibility: that private declarations are just suggestions denoted by a naming convention (e.g. prepending an underscore), but beyond that are not meaningfull.

1 Like

do you have an example of that in a library or in the stdlib?

Of the underscore convention? Doing a Base.<tab> at the repl makes me think it’s pretty common in the standard library (I’m greeted with a tonne of underscored names, e.g. Base._memcpy! and Base._pointer, which I presume are “private” methods.

The “using” thing is something I just learned too (I’m pretty new to the language myself):

module MyModule

function pubfun()
    println("This is a public function")

function _prifun()
    println("This is a private function")

export pubfun


# Un-exported stuff stays out of global namespace on "using"
using .MyModule
This is a public function
UndefVarError: _prifun not defined

 [1] top-level scope at In[3]:17

# But is ultimately still accessible
import .MyModule
This is a private function

so I guess I was wrong to say that declaring things private is totally “meaningless”, but clearly the language is using a sort of “house-sitter” philosophy to module-member visibility (i.e. you know what rooms you’re not supposed to be in, but nobody is really stopping you).


I’m a firm believer in house sitter model in any interpreted language. The basic reason is that if you want to call something and the language “doesn’t let you”, you could always just copy and paste the source. Given that, why make life harder for your users?

1 Like