Menu
Search

API Documentation

version 2.109.1

overview

View source code
Display the source code in object.d from which this page was generated on github.
Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using local clone.

Template object.imported

Provides an "inline import", i.e. an import that is only available for a limited lookup. For example:

template imported(string moduleName) ; 
void fun(imported!"std.stdio".File input)
{
    ... use File from std.stdio normally ...
}

There is no need to import std.stdio at top level, so fun carries its own dependencies. The same approach can be used for template constraints: 

void fun(T)(imported!"std.stdio".File input, T value)
if (imported!"std.traits".isIntegral!T)
{
    ...
}

An inline import may be used in conjunction with the with statement as well. Inside the scope controlled by with, all symbols in the imported module are made available: 

void fun()
{
    with (imported!"std.datetime")
    with (imported!"std.stdio")
    {
        Clock.currTime.writeln;
    }
}

The advantages of inline imports over top-level uses of the import declaration are the following:

  • The imported template specifies dependencies at declaration level, not at module level. This allows reasoning about the dependency cost of declarations in separation instead of aggregated at module level.
  • Declarations using imported are easier to move around because they don't require top-level context, making for simpler and quicker refactorings.
  • Declarations using imported scale better with templates. This is because templates that are not instantiated do not have their parameters and constraints instantiated, so additional modules are not imported without necessity. This makes the cost of unused templates negligible. Dependencies are pulled on a need basis depending on the declarations used by client code.

The use of imported also has drawbacks:

  • If most declarations in a module need the same imports, then factoring them at top level, outside the declarations, is simpler than repeating them.
  • Traditional dependency-tracking tools such as make and other build systems assume file-level dependencies and need special tooling (such as rdmd) in order to work efficiently.
  • Dependencies at the top of a module are easier to inspect quickly than dependencies spread throughout the module.

See Also

The forum discussion that led to the creation of the imported facility. Credit is due to Daniel Nielsen and Dominikus Dittes Scherkl.

Authors

Walter Bright, Sean Kelly

License

Boost License 1.0.