4 ms·

If you have a publicly visible interface, that's a name. It may be a name of a base type but it's still a name. IIRC, you can't even typeof() an instance of a V

If you have a publicly visible interface, that's a name. It may be a name of a base type but it's still a name. IIRC, you can't even typeof() an instance of a Voldemort type. That has some implications for how Voldemort types work that can't be replicated with anonymous interface implementations. The main one is, Voldemort types are very thoroughly sealed. There is no way to create an instance of one outside of the function where it's defined. With an interface, anyone else could come along and create their own implementation.

klodolph 6y ago
> With an interface, anyone else could come along and create their own implementation. Not true in Rust, because the type returned by the function is a concrete type. I think we may be overloading “name” here, a bit. If you return an “impl” in Rust, you have to name an interface, but you can’t actually create new instances of the concrete type returned by the function.
- mumblemumble 6y ago
  > Rust, you have to name an interface, but you can’t actually create new instances of the concrete type returned by the function. I think that's the distinction that really matters. The thing that's neat about Voldemort types, and gives them their interesting properties that are distinct from anonymous types, is that they have no name at all. Not even an interface or trait name.
  - skohan 6y ago
    What would be a concrete use case which benefits from this? I am not experienced with D, but it just seems like it would make code more obscure
    - mumblemumble 6y ago
      There's a bit more explanation on the D wiki: https://wiki.dlang.org/Voldemort_types https://wiki.dlang.org/Voldemort_types I don't really intend to say whether they are better or worse than other ways of accomplishing similar things. Just that they're different.
      - klodolph 6y ago
        Yes, from that explanation it sounds like they are equivalent to Rust’s impl return types. Note that interfaces in Rust are not types, they do not name types. A value cannot have interface type. What happens when you return an “impl” type is that you return some unspecified type, but that type must implement the specified interface. You could translate the D example to: trait HasGetValue { fn get_value(&self) -> i32; } fn create_voldemort_type(value: i32) -> impl HasGetValue { ... } The “create_voldemort_type” function simply returns a value of unspecified type. As far as I can tell, this is equivalent to the D code, except it doesn’t use type inference for the function type.
        moonchild 6y ago
        Not really. Part of the point of voldemort types is that no information about the type is 'leaked' outside the function. In this case, the trait 'HasGetValue' is leaked and can be used by other code.
        skohan 6y ago
        When would you want to have an interface such that nothing about the return type of a function is known to the outside world? I'm genuinely asking; I just don't understand the utility of this concept.
        mumblemumble 6y ago
        I don't think anyone's trying to argue about whether it's better or worse than the Rust concept. Just that it's subtly different.
        skohan 6y ago
        I'm not interested in comparing it to the rust concept. I'm just curious why this is something people find valuable in D, and why another commenter would call it a feature D "would be ruined without"
wwright 6y ago
You may be thinking of Java's idea of an interface, which is a type (with specific subtyping behaviors). Traits in Rust are not types. There are two different ways to reference an object which implements a trait indirectly (actually more, but these are the dominant ones): - a `Box<dyn Trait>` is like a Java object referenced by an interface. Everything uses dynamic dispatch, and it is an actual concrete type (though the actual "underlying" type is type-erased). - an `-> impl Trait` is an existential type which uses a trait as a bound, which should be equivalent to D's "Voldemort" types, except that it can still satisfy Trait requires for other functions. For example, if you `-> impl Iterator<Item = u32>`, you can pass that result to a function expecting an iterator of `u32`. However, the type is fully defined by the callee and can't be instantiated/inspected externally.

klodolph 6y ago

> With an interface, anyone else could come along and create their own implementation. Not true in Rust, because the type returned by the function is a concrete type. I think we may be overloading “name” here, a bit. If you return an “impl” in Rust, you have to name an interface, but you can’t actually create new instances of the concrete type returned by the function.

mumblemumble 6y ago
> Rust, you have to name an interface, but you can’t actually create new instances of the concrete type returned by the function. I think that's the distinction that really matters. The thing that's neat about Voldemort types, and gives them their interesting properties that are distinct from anonymous types, is that they have no name at all. Not even an interface or trait name.
- skohan 6y ago
  What would be a concrete use case which benefits from this? I am not experienced with D, but it just seems like it would make code more obscure
  - mumblemumble 6y ago
    There's a bit more explanation on the D wiki: https://wiki.dlang.org/Voldemort_types https://wiki.dlang.org/Voldemort_types I don't really intend to say whether they are better or worse than other ways of accomplishing similar things. Just that they're different.
    - klodolph 6y ago
      Yes, from that explanation it sounds like they are equivalent to Rust’s impl return types. Note that interfaces in Rust are not types, they do not name types. A value cannot have interface type. What happens when you return an “impl” type is that you return some unspecified type, but that type must implement the specified interface. You could translate the D example to: trait HasGetValue { fn get_value(&self) -> i32; } fn create_voldemort_type(value: i32) -> impl HasGetValue { ... } The “create_voldemort_type” function simply returns a value of unspecified type. As far as I can tell, this is equivalent to the D code, except it doesn’t use type inference for the function type.
      - moonchild 6y ago
        Not really. Part of the point of voldemort types is that no information about the type is 'leaked' outside the function. In this case, the trait 'HasGetValue' is leaked and can be used by other code.
        skohan 6y ago
        When would you want to have an interface such that nothing about the return type of a function is known to the outside world? I'm genuinely asking; I just don't understand the utility of this concept.
        mumblemumble 6y ago
        I don't think anyone's trying to argue about whether it's better or worse than the Rust concept. Just that it's subtly different.
        skohan 6y ago
        I'm not interested in comparing it to the rust concept. I'm just curious why this is something people find valuable in D, and why another commenter would call it a feature D "would be ruined without"

wwright 6y ago

You may be thinking of Java's idea of an interface, which is a type (with specific subtyping behaviors). Traits in Rust are not types. There are two different ways to reference an object which implements a trait indirectly (actually more, but these are the dominant ones): - a `Box<dyn Trait>` is like a Java object referenced by an interface. Everything uses dynamic dispatch, and it is an actual concrete type (though the actual "underlying" type is type-erased). - an `-> impl Trait` is an existential type which uses a trait as a bound, which should be equivalent to D's "Voldemort" types, except that it can still satisfy Trait requires for other functions. For example, if you `-> impl Iterator<Item = u32>`, you can pass that result to a function expecting an iterator of `u32`. However, the type is fully defined by the callee and can't be instantiated/inspected externally.