Note: Imported names/paths are made up, and are intentionally made more complicated for the sake of showing off features. For example,
firstname.lastname@example.org is likely to just sit in either
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 email@example.com; // 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:
… which have some benefits (more clarity of path resolution, for one), but also downsides (no
firstname.lastname@example.org.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 email@example.com.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 firstname.lastname@example.org; // available *only* as email@example.com.File import firstname.lastname@example.org: File; // available *only* as File import email@example.com; // available *only* as f.File import firstname.lastname@example.org: 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 email@example.com; // the default; generally bad style, but provided for completeness public import firstname.lastname@example.org; // available to all importers package import email@example.com; // 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.