3 weeks to delegation! Please help

[atheer]

A couple of points

Project                 Occurences of "delegating methods"
rust-lang/rust          845
rust-lang/cargo 	38
servo/servo 	        314

I think it would be a good idea to get these numbers in percentages (i.e. out of how many total methods), since it would help put the magnitude of this issue into perspective.

Secondly, wasn’t there effort to implement inheritance in Rust? If so, wouldn’t that make this RFC redundant?

[zackw]

Is the word “delegate” really appropriate in this context? I associate it with a complicated and confusing feature of C# that seems like it does a lot more than this (to be fair, I have never actually learned C#). This proposal is just syntactic sugar for wrapper functions.

I like the idea of having syntactic sugar for wrapper functions, to be clear, I just don’t want to give people the impression that this does more than it really does.

(Obligatory paint color suggestions:

impl TR for S {
    use self.f::TR;
}

impl TR for T {
    use self.f::foo;
    use self.f::bar;
    use self.f::MAX;
    type Item = /* ... */;
}  

I don’t think use already means something else in this context.

[Ixrec]

I’d like to see percentages too. I suspect no one’s gotten around to it simply because motivation was never a major concern with this RFC.

I’m not aware of any effort to add “inheritance” to Rust. But many or all of the useful features that “inheritance” typically encompasses either already exist in Rust or have been proposed/discussed various times. Traits and trait objects obviously provide interface inheritance and dynamic dispatch/runtime polymorphism. Implementation inheritance, even in OOP languages, is typically better off as composition so Rust is unlikely to add that directly. The times when implementation inheritance is most useful are mostly:

• When you want certain efficiency or memory layout guarantees that OOP languages often give. In Rust, the many proposed solutions to that problem are typically lumped together under the dubious term “virtual structs”. See https://github.com/rust-lang/rfcs/issues/349 for the exact constraints and ideas so far. It’s likely that one or more features will be added to address this problem, and the “trait fields” idea is probably going to be one of them.
• When you want to “reuse code” from another type without writing a lot of tedious wrapper code. That’s the use case this delegation proposal targets. So as far as I know, this does not overlap with any of the other proposals.

Is the word “delegate” really appropriate in this context? I associate it with a complicated and confusing feature of C# that seems like it does a lot more than this (to be fair, I have never actually learned C#). This proposal is just syntactic sugar for wrapper functions.

To me, C# delegates are a really weird name for what I normally call “an event handler” or “the observer pattern” in other languages like Javascript and C++ where it’s not a core language feature. As far as I know, “delegate” is not used that way by any other language, so I’m not personally worried about confusion. I’m also not aware of any other good names for this feature, though that may just be because there hasn’t been much brainstorming for it.

[BatmanAoD]

I like the proposal to use a new, semantically-clear keyword, though arguably delegate is a little too long. And I think overall this is a much nicer proposed syntax than the alternatives you’ve listed (though I didn’t read the original proposal thread).

I have a few quibbles, and a quickly sketched alternative syntax that I believe resolves them:

• The items being delegated (* or fn foo, fn bar...) should be listed after the delegated-to member, because, to me, the key information in such a declaration is “this trait is implemented by this member,” not the specific names of the members of the trait.
• When members are explicitly listed rather than globbed, the line quickly becomes long and difficult to read.
• The pattern of using a glob but partially overriding it seems potentially confusing.

Here’s my proposal:

We introduce delegate blocks, which are like impl blocks, except that their definitions are “forwarding” rather than from-scratch. A delegate block declaration is the same as an impl block declaration, but uses the delegate keyword in stead of the impl keyword:

delegate TR for S {
    ....
}

(The reason for introducing a new type of block is twofold: (1) I think that forwarding or delegating is simply very semantically different from implementing, and (2) this prevents any confusion or ambiguity, now or in the future, with the syntax of impl blocks.)

Within the block, members of TR are aliased to members of S, or submembers (recursively):

delegate TR for S {
    fn foo = self.foo;
    fn bar = self.baz;
    fn baz = self.f.g.h.baz;    // Equivalent to `impl TR for S { fn baz(args...) { self.f.g.h.baz(args...) } }`
}

When the names of the members of TR being aliased match the names of members of S or some subobject, the following syntax may be used:

delegate TR for S {
    fn bar = self.f.*;                           // Equivalent to `fn bar = self.f.bar;`
    type Item = <S as F>::G::*;                  // Equivalent to `type Item = <S as F>::G::Item;`
    [fn foo, const MAX] = self.*;                // Equivalent to `fn foo = self.foo; const MAX = self.MAX;`
}

To delegate an entire trait to a member of S, additional syntactic sugar (replacing the entire block with a single alias) can be used:

delegate TR for S = S.f;

This would be equivalent to:

delegate TR for S {
    [fn foo, fn bar, ...... (all members listed explicitly)] = S.f.*;
}

It is an error to use this non-block sugared syntax in conjunction with any other delegation on TR.

[BatmanAoD]

A shorter alternative for the delegate keyword would be fwd (short for forward). Not that I want to go down the Perl route of minimizing the character count of every language construct…

[withoutboats]

I’m glad people are working on this space, but I want to note that I still have the concern I described on the other RFC thread about how, right now, I feel a real lack of clarity around what self means in this syntax. At least this should be described with more clarity and with consideration of future extensions it may enable or foreclose.

[Ixrec]

The items being delegated (* or fn foo, fn bar…) should be listed after the delegated-to member, because, to me, the key information in such a declaration is “this trait is implemented by this member,” not the specific names of the members of the trait.

Now that you mention it, I agree with that. I guess my proposed syntax would now be delegate to self.f for *;

(1) I think that forwarding or delegating is simply very semantically different from implementing

Now that’s interesting. AFAIK delegation is just one way of implementing something, this delegation sugar is intended to be interchangeable with manually written delegations, and it’s not supposed to be something client code is aware of. What’s the semantic difference you see? I didn’t see any proposed semantic differences in your post, so I’m not really sure how to argue this other than “it’s sugar, it has no semantics beyond what it desugars to”.

The pattern of using a glob but partially overriding it seems potentially confusing.

We may need more people to chime in on whether this is true, but to me the pattern of delegating almost all items except for one or two that you want to change is a very common use case and valuable part of the feature. I also don’t want the transition from “delegating everything” to “delegating all but one thing” to require replacing * with an exhaustive list of all the other items.

Did you have a less confusing syntax in mind for this use case, or do you not want to support it at all? IIUC your proposal simply doesn’t support it.

[Ixrec]

Could you expand on this? Do you mean a lack of clarity about what these proposals desugar to? Or something conceptual about what the self keyword is supposed to “be” in these delegation statements/blocks prior to desugaring? I guess it’s a little weird to delegate a static method to self.f, but it seems obvious what it should do regardless.

[ssokolow]

We may need more people to chime in on whether this is true, but to me the pattern of delegating almost all items except for one or two that you want to change is a very common use case and valuable part of the feature. I also don’t want the transition from “delegating everything” to “delegating all but one thing” to require replacing * with an exhaustive list of all the other items.

Did you have a less confusing syntax in mind for this use case, or do you not want to support it at all? IIUC your proposal simply doesn’t support it.

I agree that I wouldn’t want such a transition from “all” to “all but one” to be so catastrophic (I code without an IDE to automate refactoring), though I do also want to be cautious about making the compiler too lenient when it comes to how newcomers might get misled about what’s actually going to get called.

As such, only wildcards should support that kind of shadowing. (ie. delegate to self.f for foo; followed by fn foo in the same scope should be an error, just as two fn foo in the same scope is an error.)

That said, as I see it, the issue stems from how “delegate” doesn’t carry the connotation of providing default values or declaring a lower layer in a stack of overlays which inheritance does, which is a bigger comprehension problem in Rust than in languages like Python because, in more dynamic languages, it’s a simple case of “last declaration wins”, just like with variables.

…so I see two options:

1. Go with delegate or use or what have you and just live with having to teach that "* is special. It just is."
2. Come up with a word with connotations more like “inherit from” or “fallback to” and accept having to teach that the compiler will only allow shadowing/hiding/overriding a “fallback” if it’s pulled in via a wildcard.

I’m partial to the former (just teach that “*” is special) because, to me, it makes sense and shouldn’t be difficult to teach that, if you’re wildcarding from someone else’s interface, them adding a bar function shouldn’t cause your wrapper to fail to compile if it already has a bar.

[steven099]

To me, C# delegates are a really weird name for what I normally call “an event handler” or “the observer pattern” in other languages like Javascript and C++ where it’s not a core language feature. As far as I know, “delegate” is not used that way by any other language, so I’m not personally worried about confusion.

It’s used extensively in Objective C / Swift. The thing is that the delegate (n. /ˈdɛlɪɡət/) is the value/type to which you delegate (v. /ˈdɛlɪˌɡeɪt/) functionality. C# has /ˈdɛlɪɡət/s, while I believe this proposal is about /ˈdɛlɪˌɡeɪt/ing.

[Ixrec]

As such, only wildcards should support that kind of shadowing. (ie. delegate to self.f for foo; followed by fn foo in the same scope should be an error, just as two fn foo in the same scope is an error.)

100% agree. This was definitely my intent in my earlier posts.

That said, as I see it, the issue stems from how “delegate” doesn’t carry the connotation of providing default values or declaring a lower layer in a stack of overlays which inheritance does …

Part of the reason I opted to have an explicit * in my proposal rather than just delegate to self.f; was because I felt an “explicit *” helped carry exactly these sorts of connotations. I believe it already has a sort of “everything you need, not necessarily everything that’s available” connotation from glob imports. Maybe I should’ve mentioned this earlier.

[ssokolow]

Part of the reason I opted to have an explicit * in my proposal rather than just delegate to self.f; was because I felt an “explicit *” helped carry exactly these sorts of connotations. I believe it already has a sort of “everything you need, not necessarily everything that’s available” connotation from glob imports. Maybe I should’ve mentioned this earlier.

That makes sense and I’m with you on that perspective and I see it as intutive because * would be “pretty silly” (technical term :P) if it did anything but what you’re proposing.

[BatmanAoD]

AFAIK delegation is just one way of implementing something, this delegation sugar is intended to be interchangeable with manually written delegations, and it’s not supposed to be something client code is aware of. What’s the semantic difference you see?

Perhaps “very semantically different” was the wrong phrase. What I mean is simply that, as an author and a reader of code, impl means “definitions will be provided here,” while delegate means “aliases will be provided here,” and knowing in advance which I am looking at would, I think, simplify the reading process, and possibly the syntax. You are correct that there would be no difference in client code or calling convention, except possibly as an optimization if the trait implementation is known at compile time (i.e. no runtime dispatch) and the alias is available during inlining; in this case, presumably, the alias target could be invoked directly.

So my intent in using the word “semantic” was precisely to indicate a difference that doesn’t really matter in its de-sugared form, but may matter to the programmers working on the project.

That said, I don’t feel particularly strongly about this. Primarily, I wanted aliasing to go in its own block because I think it just looks a little cleaner and won’t require a change to the existing impl block syntax.

Did you have a less confusing syntax in mind for this use case, or do you not want to support it at all? IIUC your proposal simply doesn’t support it.

No, I do not have an alternate syntax in mind. I would prefer something that explicitly shows either the included members or the excluded members, a la this Bash-ism (I know, I know, it’s hideous):

delegate TR for S {
    [* !(fn foo, fn bar)] = S.f.*;
}

… or even yet another contextual keyword:

delegate TR for S {
    [* except fn foo, fn bar] = S.f.*;
}

…but I don’t have a strong rationale for this, I suppose, and I guess it’s okay if [*] means something like Ruby’s method_missing.

I guess it’s a little weird to delegate a static method to self.f, but it seems obvious what it should do regardless.

For static methods, I’m actually not sure what a delegate would be supposed do, assuming f is something like an instance variable.

[Ixrec]

I would prefer something that explicitly shows either the included members or the excluded members

That makes sense. I could live with delegate to self.f for * except fn foo;, though I still think delegation should happen inside an otherwise-normal impl block so it might look redundant to say “except fn foo” only one line above your “fn foo” definition.

For static methods, I’m actually not sure what a delegate would be supposed do, assuming f is something like an instance variable.

I have no idea whether this is a real use case, but I was imagining it’d do this:

trait MagicNumber {
    fn num() -> i32;
}

struct A {}

impl MagicNumber for A {
    fn num() -> i32 {
        42
    }
}

struct B {
    a: A
}

impl MagicNumber for A {
    delegate to self.a for *;

    // desugars to...

    fn num() -> i32 {
        A::num()
    }
}

Actually writing that out made me really question whether I want the self in the delegation statement anymore…

[BatmanAoD]

For static methods, I really don’t think self should be included:

impl MagicNumber for A {
    delegate to B for *;
}

…because this is exactly what you’re actually doing: some static methods of A are identical to corresponding static methods of B, so they’re aliased. No instances are involved at any point.

[steven099]

I mean, you could go all the way to require the type always:

delegate to B at self.b for *;

You’d only need an at clause when there are methods. The challenge with doing

delegate to B ... 

and

delegate to self.b ...

is that you have a context that accepts either a value or a type, when these are parsed differently.

This also opens he door to

delegate to B at Default::default() for *;

[ssokolow]

though I still think delegation should happen inside an otherwise-normal impl block so it might look redundant to say “except fn foo” only one line above your “fn foo” definition.

I agree, for the following reasons:

1. Having a separate block for delegation seems counterproductive to me. I don’t think it looks any cleaner to do delegation in a separate block and it feels like yet another subdivision of where I have to look to get a sense of where each function comes from and what it is.

   (In fact, if you’re only delegating one thing or only impling one thing, then it adds at least two extra lines of clutter for no benefit at all.)

   EDIT: Actually, now that I think about it, doing delegation in a separate block sort of reminds of C++'s approach to distinguishing between public, protected, or private member declarations… for what it’s worth.

2. I don’t want to have to repeat myself, needlessly keeping two lists of what I’ve implemented in sync. (the “don’t delegate” list and the “here are the implementations” list.)

[F001]

impl MagicNumber for A { delegate to self.a for *;

Shouldn’t the second impl block be:

impl MagicNumber for B {
   delegate to self.a for *;
}

But there is a question that what is the type of self in delegate statement? B or &B or &mut B?

What about this alternative:

impl MagicNumber for B {
   delegate * to Self::a;
// or
   delegate * to B::a;
}

But when it comes to multiple layers, B::a::c is wrong.

What if the field a is &A type, but there is a method in MaticNumber requires Self type? There should be a clear error message to describe what is wrong.

[F001]

There is another concern that how delegate interacts with specialization.

There will be an default impl block in the future. Should we allow delegate be used in default impl block? I suppose not, at least for now, to push this RFC as quickly as possible.

[BatmanAoD]

what is the type of self in delegate statement? B or &B or &mut B?

When aliasing functions, the declaration of the delegate function is visible; the qualification of self is therefore part of the function arguments list, which will be shared identically between the original function (the one being listed as an alias target) and the alias itself.

For member variables, access will of course depend on context.