I think it's unfortunately too late to overhaul the language like this. This
will require redesigns of all Rust code in existence.
I do like unified function/method call syntax, but I think it can be done in a
backwards compatible way.
Patrick
"Gábor Lehel" <illiss...@gmail.com> wrote:
>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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity._______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
