On Sat, Oct 19, 2013 at 4:08 PM, Oren Ben-Kiki <o...@ben-kiki.org> wrote:
>
> I'm less certain about giving up `impl Foo { ... }`, though - that is
> useful for logically grouping, documenting and accessing functions (as in
> `Foo::foo(...)`). But it seems we don't have to give it up, just make it
> optional?
>
Interesting point. I think this argues in favor of removing anonymous
`impl`s, even as sugar. I was focused on normal ("selfish") methods in my
previous letter, rather than "static" ("selfless") ones. You could still
achieve much the same effect, if you wanted to, by writing:
struct Foo { .. }
fn get_thing(self: &Foo) -> Bar { .. } // for `some_foo.get_thing()`
syntax
mod Foo {
fn new() -> Foo { .. } // for `Foo::new()` syntax
}
Rust already allows this trickery: the type and module are imported
together when you write `use some_mod::Foo`. Keeping this seems fine, and
making it more explicit (relative to `impl`) seems like a good thing. What
you lose is that in the case of a generic type, you would have to write the
generic-bits for each function, which is the "more typing" disadvantage
from earlier. I think losing the `impl` sugar is a small price to pay for
the simplification of the language. Modules would be modules and types
would be types. Append to the "advantages" list:
- The complexity related to (possibly-generic) types in paths would go away
On Sat, Oct 19, 2013 at 3:47 PM, Matthieu Monrocq <
> matthieu.monr...@gmail.com> wrote:
>
>> I see no reason for the restriction of "self". Why not simply say that
>> any function can be called with "first_arg.func(...)" style ?
>>
>
Yeah, as I mentioned in the last bullet of the previous letter, you could
do this. I don't think it makes much difference either way and don't have a
strong opinion.
In favor of explicit `self` is that it's, well, explicit: "you can and
should call this using method syntax". I can imagine there might be
function signatures where using method syntax wouldn't make sense (though
you might say, "then don't use it", and I would be inclined to agree). A
non-method function (one without a `self` arg) also wouldn't cause
ambiguity if it were in scope at the same time as you were calling another
method with the same name.
In favor of always allowing method syntax on the first argument is that you
could destructure it in the definition, e.g. `fn area((x, y): (int, int))
-> int { x * y }`, and still call the function using method syntax.
They're all pretty minor.
--
Your ship was destroyed in a monadic eruption.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
