Imports
Note: Imported names/paths are made up, and are intentionally made more complicated for the sake of showing off features. For example, std@io.file
is likely to just sit in either std@io
or std@file
directly.
The syntax for imports is not finalized, but most of the semantics are. The most likely option is heavily inspired by D.
// TODO: Not happy with this syntax. I like `std:io.file` visually the most, but that's ambiguious. Perhaps `std::io.file` (despite my dislike for double colon), `std\io.file`, or such?
import std@io.file;
// another alternative (but it eliminates the concept of explicit packages)
import std.io.file;
The other option to above would be to have string-based imports:
import "std:io/file.coy";
… which have some benefits (more clarity of path resolution, for one), but also downsides (no std@io.file.File
or such access).
In the first 2 cases, the imported symbols are available either directly, or via a fully-qualified name:
var file = new std@io.file.File("some_file.txt");
// either equivalent or an ambiguity error (depending on how many imported modules define the symbol)
var file = new File("some_file.txt");
Only the latter is supported in the case of import "std:io.file"
. But see below for renaming options.
There also exist partial and renamed imports:
static import std@io.file; // available *only* as std@io.file.File
import std@io.file: File; // available *only* as File
import f=std@io.file; // available *only* as f.File
import f=std@io.file: File; // ERROR; illegal (TODO: could make it available as f.File *and* File?)
All imports are private by default, but the symbols may be made available transitively to other files that import the current one:
// TODO: Is this feature worth the added (admittedly minor) complexity?
private import std@io.file; // the default; generally bad style, but provided for completeness
public import std@io.file; // available to all importers
package import std@io.file; // available to importers in the same package
Note that a “bad style” option is allowed. It is the philosophy of the language that programmer ultimately knows best when it comes to code style. For example, an explicit private import in a sea of public ones may be beneficial.