Estilos de importação

add vem de use lib_demo::add; sub e get_pi chegam pela lista. Ambas as formas funcionam juntas no mesmo arquivo.

// Feature: qualified access vs. imported name — when to use each
// Syntax: `lib::foo()` (qualified) vs. `foo()` (after `use`)
// When to use:
//   - qualified: module is large and names are generic
//     (e.g. `time::now`, `math::sqrt`); makes origin clear
//   - imported: name is unique and used a lot; reduces noise

mod lib_demo

// Imports only `add` — uses `add(...)` directly.
use lib_demo::add

// SKIP: `use lib_demo` alone (for qualified access elsewhere in
// the file) is rejected by the loader. Pull every name explicitly.
use lib_demo::{sub, get_pi}

fn main() {
  // Imported: call directly.
  let s = add(10, 5)
  print("add direct = {s}")

  // expected: add direct = 15

  let d = sub(10, 5)
  print("sub = {d}")

  // expected: sub = 5

  print("pi = {get_pi()}")
  // expected: pi = 3.14159
}

use lib_demo::greet (única) e use lib_demo::{add, sub, VERSION} (lista) convivem sem conflito.

// Feature: import from more than one module in the same file
// Syntax: multiple `mod` + `use` declarations at the top
// When to use: real programs almost always combine several modules;
// declare each `mod` once at the entry-point and use them at call sites.

// Loads both files alongside: `lib_demo.zolo` and
// `multi-file/helpers.zolo` (the latter we would reference via a
// relative path embedded in the multi-file folder example). Here we
// just re-use lib_demo.

mod lib_demo

// You can mix forms (single + list). The bare `use lib_demo` form
// for qualified access is currently rejected by the loader; pull
// the constant explicitly instead.
use lib_demo::greet  // single
use lib_demo::{add, sub, VERSION}  // list

fn main() {
  greet("multi")

  // expected: Hello, multi!

  print("add = {add(2, 3)}")
  print("sub = {sub(7, 4)}")
  print("VERSION = {VERSION}")
  // expected:
  // add = 5
  // sub = 3
  // VERSION = 1.0.0
}

Para módulos .zolo do usuário, prefira a lista {a, b, c}. Reserve o wildcard ::* para plugins nativos (winit, wgpu, binary...).

// Feature: tradeoffs between `use foo::*`, list, and qualification
// Syntax: three variants — side-by-side comparison
// When to use: see the guide below for each scenario.

// === Scenario 1: many names from the same module, all from a plugin ===
// Native-plugin import -> wildcard via `use plugin` is OK and idiomatic.
//
//     use plugin winit::*
//     use plugin wgpu::*
//
// === Scenario 2: you need a few specific functions ===
// Named list -> shows exactly what is in use.
//
//     use lib_demo::{add, sub, greet}
//
// === Scenario 3: rare use, or names may collide ===
// Qualified access -> keeps origin explicit.
//
//     use lib_demo
//     ...
//     lib_demo::add(1, 2)

mod lib_demo

// Mixing strategies in a single file. Bare `use lib_demo` (for
// qualified access elsewhere) is rejected by the current loader,
// so pull the occasional name explicitly too.
use lib_demo::greet  // called several times -> direct import
use lib_demo::add  // occasional, but still imported by name

fn main() {
  // Good: direct name (frequent use).
  greet("alice")
  greet("bob")
  greet("carol")

  // expected:
  // Hello, alice!
  // Hello, bob!
  // Hello, carol!

  let s = add(2, 3)
  print("sum = {s}")
  // expected: sum = 5
}