Difference between revisions of "Voldemort types"

From D Wiki
Jump to: navigation, search
(Subverting unnameability)
(clarify)
Line 1: Line 1:
In D, a '''Voldemort type''' is a type that cannot be named outside of the scope it's declared in, but code outside the scope can still use this type by taking advantage of D's static type inference.
+
In D, a '''Voldemort type''' is a type that cannot be directly named outside of the scope it's declared in, but code outside the scope can still use this type by taking advantage of D's static type inference.
  
 
==Usage==
 
==Usage==

Revision as of 18:49, 14 December 2012

In D, a Voldemort type is a type that cannot be directly named outside of the scope it's declared in, but code outside the scope can still use this type by taking advantage of D's static type inference.

Usage

For example:

// Note: the return type is auto, because we cannot actually name it outside the function!
auto createVoldemortType()
{
    struct TheUnnameable
    {
        int nameableMember=100;
    }
    return TheUnnameable(123);
}

Here is how the Voldemort type can be used:

auto voldemort = createVoldemortType();
writeln(voldemort.nameableMember);  // prints 123

The type of the variable voldemort cannot be explicitly named here, because that name is only accessible inside the function createVoldemortType. However, we can still declare variables of that type by using D's static type inference.

Purpose

This section is a stub. Please help the wiki by adding more content here.

Voldemort types are widely used in Phobos's range-based functions. They are used as internal types that implement that particular range function. Voldemort types were chosen for this in order to improve encapsulation: users of the standard library don't need to, and shouldn't need to, know how a particular range function was implemented.

In fact, some of the range-based functions will return different types based on what kind of range was passed in. Rather than force the user to remember which type to use for which occasion, the use of Voldemort types force the user to depend on static type inference, and thus automatically get the right type every time.

This also allows the Phobos developers to change the underlying implementation without requiring all users to update their code. Otherwise, every time the implementation changes you will have to update every instance of the type to refer to the correct type name. Using Voldemort types alleviates this problem by letting the compiler fill in the correct type for you automatically.

Subverting unnameability

Although we cannot directly name a Voldemort type, there is an indirect way to refer to it using the typeof operator:

// Declares voldemort to be of the same type as the
// return type of the function createVoldemortType.
typeof(createVoldemortType()) voldemort;

writeln(voldemort.nameableMember);  // prints 100

Here, we've successfully created an instance of the Voldemort type without being able to refer to its type name directly. We can even use an alias to make our code more readable:

alias typeof(createVoldemortType()) TheNowNameable;

// Look, ma! We now have an explicit name for the Voldemort type:
TheNowNameable voldemort;
writeln(voldemort);  // prints 100

What's the point of creating a name for a Voldemort type, when the whole point of a Voldemort type, as mentioned in the previous section, is so that you don't need to know what type is? This is sometimes needed when you're writing your own generic code, and need to store instances of a type that's actually unknown at the time of writing:

struct MyRangeWrapper(R)
{
    // Note: we actually have no way of knowing what type std.range.cycle will
    // return, because it may give us a different type depending on what R is.
    alias typeof(std.range.cycle(R.init)) CycledRange;

    // But we need a name for whatever type that is, because we need to store a
    // variable of that type:
    CycledRange cr;

    this(R range)
    {
        cr = std.range.cycle(range);
    }
    ... // other wrapper functions go here
}

See also