Maximum conceptual simplicity has never been a design goal of Rust. If we
wanted maximum simplicity we would just eliminate the dot operator entirely and
use explicit existential types for trait objects like Haskell.
I know that the dot operator is additional unnecessary complexity. No argument
there. The thing is that the lookup rules are complexity I think we should buy
into because of the convenience and familiarity we get from them. We tried
explicit implementation importing, as well as having no dot operator at all, in
early versions of Rust. That language was a lot less convenient and limited
than Rust of today.
The dot operator is there to allow object-oriented programming, including
type-based method lookup. If you find OO distasteful, then you should be able
to avoid use of the dot operator and still program Rust without loss of
functionality (well, first-class trait objects excepted). That is what I had in
mind with UMCS.
As for some of the specifics in your list, I'd like to fix them. For example, I
was going to bring up allowing custom smart pointer self types, as well as
allowing "use" from impls, at a meeting soon. In general I have been thinking
that type implementations and traits should be considered modules and should
admit everything that can appear in a module.
Patrick
"Gábor Lehel" <illiss...@gmail.com> wrote:
>On Sun, Oct 20, 2013 at 9:38 PM, Patrick Walton <pwal...@mozilla.com>
>wrote:
>
>> I guess I just don't see the value in requiring imports of names when
>> there can be no ambiguity and they're defined in one place (the impl
>of the
>> type, defined in the same place as the type itself). One person's
>"magic"
>> is another person's "smart compiler".
>>
>
>A big part of the motivation would be to allow declaring methods
>anywhere,
>without using traits, and then "they're defined in one place" stops
>being
>true. For that to be workable you need to have control over imports.
>(Luckily with top-level functions, you already do.)
>
>
>
>> I'm not convinced that this is solving a real problem.
>>
>
>It's not "solving a real problem" so much as simplifying the whole
>thing.
>Despite having used the word, my beef with the current system is not so
>much that it's magical. It's that it's completely unnecessary. With
>nothing
>more than a simple syntax rule and the existing module system, you can
>recover all of the expressive power of the current system, and more.
>
>Compare:
>
>
>-- Design 1 --
>
> - You can declare functions using `fn`.
>
>- Functions in the current scope can be called using dot syntax with
>the
>first argument as the receiver. (Optionally: only if the first argument
>is
>named `self`.)
>
> - The module system can be used to group types, functions, and other
>items, import them together, selectively, or under different names, and
>resolve ambiguities between them.
>
>
>-- Design 2 --
>
>- Anonymous `impl` blocks can be used to associate methods with a type.
>
>- Methods are scoped under and imported together with their type or
>trait.
>
>- Because of this, an anonymous `impl` can only be declared in the same
>module as its type.
>
> - If you want to declare a method somewhere else, declare an auxiliary
>trait and implement it for that type.
>
>- For a method to be called with dot syntax, it has to be declared
>using
>special `self`, `&self`, `~self`, (or so forth) syntax, which only
>works
>with the built-in pointer types. Such a method can't be called with
>function syntax.
>
>- If you want a self-type other than one of the built-in pointers,
>write
>an `impl` specifically for that type.
>
>- Types and traits are like modules in some ways (you can use them in a
>path), but not others (you can't `use` from them).
>
>- There are special rules and/or syntax for dealing with traits,
>generic
>types, and optionally their type arguments in paths.
>
>- In addition to methods, you can also declare top-level functions with
>`fn`. These can only be called with function syntax.
>
> - The module system can be used to group, import, rename, and resolve
>ambiguities between types, functions, and other items except for
>methods.
>
>Which one feels like the tighter design?
>
>With some extensions (methods can be called with function syntax,
>in-scope
>functions are also considered during method lookup), Design 2 could
>close
>the expressiveness gap versus Design 1. But the simplicity gap would
>remain.
>
>
>
>> The "search all traits in scope" behavior strikes me as far more
>magical
>> than this.
>>
>
>All of that said, maybe I'm insufficiently worked up about the method
>lookup rules. :) Searching trait impls does sound a little bit scary.
>What
>about, as a less scary in-between solution, while not throwing the baby
>out
>with the bathwater, attempting to unify the type of the receiver with
>the
>types of the first (`self`) arguments of the functions of the given
>name in
>the current scope, but *not* looking at trait impls? And if there's a
>unique match (modulo autoborrowing and such) it's selected, otherwise
>an
>error is reported. Whether appropriate trait impls exist would be
>checked
>after a method is selected. This means that if you have a trait method
>or
>function in scope which is generic in its self-type, and any other
>function
>which also matches the type of the receiver, it would lead to
>ambiguity.
>But as (in my proposal) you would no longer have to use traits to
>implement
>extension methods, this would hopefully be a less common occurrence.
>
>Again though, I think this can and should be considered as a separate
>matter. It could be done inside the current system, I think, if you
>wanted
>to. The differences in the context of my proposal are the
>aforementioned
>not having to use traits for extension methods, and that you would have
>more ways to resolve an ambiguity.
>
>
>It's probably easier to list languages that *don't* have this feature
>in
>> some form than to list languages that do, honestly...
>>
>
>That's because all of the mainstream languages follow misguided OO
>ideas,
>and most of the others copy them. :-)
>
>
>--
>Your ship was destroyed in a monadic eruption.
--
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
