I like this too. If this does unify methods and functions, will this allow us to eventually do a move out of self (#3724)?
On Mon, Dec 10, 2012 at 8:15 AM, Niko Matsakis <[email protected]> wrote: > I am a fan of this idea. > > > > Niko > > > Patrick Walton wrote: > >> Hi everyone, >> >> This has been proposed in some form several times by different people, >> and I think we could possibly make it work now. It would be a low-priority, >> backwards-compatible change that would make the language somewhat simpler. >> >> Today, there is the distinction between static methods (invokable as >> functions, but not using dot notation) and non-static methods (invokable >> using dot notation, but not as functions). This proposal would unify the >> two. >> >> Briefly, suppose that we have a method call like: >> >> a.foo(b, ...) >> >> Assuming `a` does not have object type, this would be equivalent to this: >> >> NAMESPACE::foo(OPERATION(a), b...) >> >> Where `NAMESPACE` is one of: >> >> 1. The anonymous trait associated with the type of `a`, if `a` is an enum >> or struct (or coercible to one, or a pointer to one) and has an anonymous >> trait defined for it. (Note on terminology: the "anonymous trait" is the >> new name for a "trait-less impl" or "an inherent implementation".) >> >> 2. The traits in scope at the call site. >> >> And `OPERATION` is one of: >> >> 1. One or more dereference operations (`*a`). >> >> 2. An address-of operation (`&a`, `&const a`, `&mut a`). >> >> 3. A coercion from `~[T]` or `@[T]` to `&[T]` (or the mutable variants to >> the corresponding mutable slice) followed by an address-of operation. (This >> is probably the ugliest rule here, but it seems necessary to allow `for [ >> 1, 2, 3 ].each |x| { ... }` to work.) >> >> So, in our example above, if `a` had type `T`, we might transform >> `a.foo(b)` to `T::foo(&a, b)`. >> >> The other change that needs to happen is that what we've been calling >> "explicit self" needs to become syntactic sugar for an explicit first >> argument. For instance: >> >> struct T { ... } >> >> impl T { >> fn foo(&self, b: int) { ... } >> } >> >> Is exactly the same as: >> >> struct T { ... } >> >> impl T { >> /*static*/ fn foo(self: &T, b: int) { ... } >> } >> >> (The keyword `static` is commented out because, while it is necessary >> today for backwards compatibility, it will not be necessary, and in fact >> will likely be removed, in the near future.) >> >> The most immediate practical benefit of this would be that methods that >> today must be invoked with dot notation would become useful as arguments to >> higher-order functions. The other main benefit is that the language design >> becomes simpler and tidier. We no longer need to think of the method call >> as a core construct in the language (except for objects) but rather as a >> form of sugar guided by scope and type information. >> >> Again, none of this is particularly high-priority, as I don't think it'll >> have much immediate practical impact, but I do think it's a simplification >> worth considering. >> >> Thoughts? >> >> Patrick >> ______________________________**_________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >> > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
