Syntax proposal: Accessing non-exported names

[jinwoo]

Julia has very little control over name visibility -- you can access any names from a module whether they are exported or not. I think it's good because it gives people more control over how to use other modules. But it'd be perfect if the client code could get more hints when it accesses non-exported names.

In Common Lisp, you can access exported symbols by foo (when foo is used) or mypkg:foo. But when you want to access non-exported symbols, it must always be done via double-colon (vs single one): mypkg::foo. It gives the client code a good warning, "You're now depending on the implementation detail. You're free to use it now but it may not be available in the next version of the package. Use at your own risk".

Can we enforce something similar in Julia? For example, with code like this:

# MyModule.jl

export greet

greet(name) = call(name, "Hello")

call(name, greeting) = "$greeting, $name!"

The client code of this module would be able to do MyModule.greet("Jane") or greet("Jane") (when usingd). But to access call, it must always do MyModule..call("Jane") (with double-period). The syntax could be something else. I just want the client code writers to receive a good hint about what they are doing.

[simeonschaub]

I am not sure we really need syntax for this. Currently the convention is that internal functions have names which start with an underscore to signify that they are not part of the public API, which seems to work pretty well.

We also can not use .. for this, since that is already a valid operator.

[jinwoo]

Using an underscore to signal non-public names is, as you said, just a convention and many packages don't follow that convention (I'm speaking more from the client code writer's point of view). As for the operator, I don't care what operator would be actually used for this. I just want a clear signal to the client code writers. Maybe MyModule#call() or MyModule@call()? I don't know. The uglier the operator is, the better :)

[simeonschaub]

It is a pretty strong convention and also used by Base, what packages did you have in mind that don't follow this convention?

Also note that a function not being exported does not necessarily mean that it is not part of the public API, i.e. CSV.jl does not export CSV.read since it conflicts with Base.read. This means that for this to be useful, users would have to manually specify which functions are part of the public API. At this point I don't think there really is an advantage over an universally understood convention, since it still requires opt-in from package developers, so we might as well just encourage them to follow the underscore convention.

I did notice however, that the underscore convention is not really emphasized in the manual. I think it would be good to add this here: https://docs.julialang.org/en/v1/manual/style-guide/#Use-naming-conventions-consistent-with-Julia-base/

[jinwoo]

Maybe the underscore convention is good enough, as it is in Python.

By the way, in my opinion, CSV.read is a good example of the limitation of the import/export mechanism though. It should've been exported because it is one of the most important APIs of the CSV package but it couldn't because of the name conflict. Maybe the situation will be better with Julia 1.6, using the new as syntax. For example, import CSV: read as readCSV.

[jinwoo]

Anyway, I'm closing this now. If the underscore convention is strong enough and widely used, I'm fine with that. Thanks for the replies.