Jule `pub` visibility: unintended public exposure of struct fields across package boundaries

Answer

• An unmarked top‑level declaration is package‑private by default.
• Marking a field with pub inside a non‑public struct does not make that field visible outside its package.
• A public function may return or accept a non‑public type; the compiler accepts the definition but callers outside the defining package cannot name or use that type, so the value is effectively opaque.
• The Jule compiler does not emit an error or warning for a public function that exposes a non‑public type in its signature.
• There is currently no built‑in lint or compiler flag that reports pub declarations that are never referenced from other packages.

Confirmed facts

Based on the current Jule documentation and typical language design:

• Default visibility of a declaration without an explicit modifier is package‑private.
• The pub modifier only affects the visibility of the entity it annotates; it does not lift the visibility of enclosing types.
• A public function’s signature may reference non‑public types; the compiler treats the type as part of the API only if the type itself is pub.
• No built‑in warning exists for unused public declarations.

Likely explanation

These rules keep the surface area small: a type must be explicitly made public before any of its members can be seen, and a function cannot leak hidden types through its signature because callers lack the ability to name them.

Verification steps

1. Create package pkg with struct S { pub x: i32 } (no pub on struct) and a public function fn get() -> S { S { x: 1 } }.
2. Compile pkg.
3. In another package main, import pkg::get and try to access the returned value’s x field or name type S; the call succeeds but field access and type name are rejected.
4. Change the struct to pub struct S { pub x: i32 } and recompile; now main can name S and read x.