On Fri, Oct 18, 2013 at 9:34 PM, Gábor Lehel <illiss...@gmail.com> wrote:
> Hi list, > > This is meant as a followup to an earlier thread[1] on the subject and the > related ticket[2]. > > [1]: http://thread.gmane.org/gmane.comp.lang.rust.devel/2622/ > [2]: https://github.com/mozilla/rust/issues/6974 > > The idea in those earlier discussions is that methods could also be called > using function syntax, supplying `self` as the first argument, so instead > of `self_arg.method(arg)`, you could write `method(self_arg, arg)`. I'm > wondering if this could be taken a couple steps further to simplify the > whole story regarding functions, methods, traits, and impls. The idea is > that the distiction between functions and methods would be erased almost > completely, and methods (now being just functions) would be imported > explicitly. > > It would involve the following pieces: > > - If the first argument of a top-level `fn` is named `self`, it can be > called using method syntax. So if you have `fn foo(self: &MyType, n: int) > { .. }` at the top level, you can write `object_of_my_type.foo(123)`. You > can also still call it using function syntax: `foo(object_of_my_type, 123)`. > I see no reason for the restriction of "self". Why not simply say that any function can be called with "first_arg.func(...)" style ? Regarding the idea in general, I like the elegance that such harmonization brings. -- Matthieu > > - Anonymous `impl`s could then be removed in favor of such top-level > `fn`s. Alternately, they could be kept as syntactic sugar for the same > thing. > > - Just as the distinction between functions and anonymous-impl methods > would be erased, the distinction between trait methods and associated > functions would also be erased. A function declared inside a trait would > exist in module scope, just like top-level `fn`s. Just like other > functions, you could call it using method syntax if the first argument is > named `self`, or using function syntax either way. > > - The existing syntax for `self` arguments could then be removed. > Alternately, it could be kept as syntactic sugar (`?self` becoming `self: > ?T`, where `?` is any sigil or none). > > - Now that everything is a top-level `fn`, they would be imported > explicitly, like they (and all other things) already are. Here we can > remove the restriction on methods needing to be declared in the same > module/crate as their `self` type. > > - Functions can be called using method syntax only if they are declared > in, or imported into, the current scope directly. In other words, if you > could call them using function syntax unqualified. > > - If a method call is ambiguous, you would have the following options to > resolve it: > > (a) Tweak your imports so that only the method you want is in scope. > > (b) Import the method under a different name instead. > > (c) Use function call syntax instead with an explicit module qualifier. > > Again, more or less the same options you have with any non-method item in > the current language. > > > Disadvantages of this scheme: > > - More typing. (Explicit imports for one; if sugar is removed, then that > as well.) > > > Advantages: > > - Simplicity and transparency. The special rules and language constructs > for declaring and importing methods would go away. Methods would work the > same way as other things do. > > - Correspondingly, you would also have better control over which methods > are imported and invoked. > > - You could declare methods for any type in any crate or module, without > having to create extraneous traits, which I feel is a wart in the current > language. Traits could then be used for abstraction only, which I feel is > their correct purpose. > > - Because methods would just be module-scope functions, they could be > referred to as values (e.g. as arguments to higher-order functions) without > a lambda shim. > > - I was confused at one point because `&self` looks a lot like a pattern > match, but is not one. That could go away. > > - The current difficulties with generic methods (`impl<T: Foo> T { .. }` > in the current language) might, or might not, be reduced. (I don't know of > any similar issues with generic top-level functions, but they might > resurface if called as methods). > > - The significance of the argument named `self` could also potentially be > removed, instead allowing the first argument to be used as the > self-argument in a method call, no matter what it's called. This would > allow for pattern matching on the self-argument in the definition of the > method, which is currently not possible. > > > Hope this is helpful or interesting, > Gábor > > -- > Your ship was destroyed in a monadic eruption. > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
