I'm not sure I follow.
Assuming that the trait `T` has no method that uses `Self`, then any `impl`
requiring `T` should happily accept an `T` / `@T`. Why penalize
non-self-referential traits (like `Writer`), just because some traits (like
`AdderIncr`) are self-referential?
On Sun, Oct 20, 2013
On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton pwal...@mozilla.comwrote:
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
It's different from everything else because it's a non-overlapping feature :)
But yes, I think being like OO is reason enough to do it. If we didn't have
that, then you'd have to import every method you call. I think that that would
turn off far too many programmers coming from mainstream
Coming from a functional programming perspective, it would still be very
nice indeed to easily pipeline a series of functions (not methods).
The current method of requiring defining a new trait (with possibly just
one impl!) just to be able to use the `.` syntax means discouraging
functional
On Sun, Oct 20, 2013 at 4:56 PM, Patrick Walton pwal...@mozilla.com wrote:
I don't see the things you mention as warts. They're just consequences of,
well, having methods in the OO sense. Nearly all of these warts show up
in other object-oriented languages too. Maybe they're warts of
It seems to me that maybe there are several concepts/changes that are
discussed at once, and it would be possible to nitpick.
Personally, when I think of unifying calls, I only think of having
foo.bar(baz) being strictly equivalent to bar(foo, baz); nothing more
than a syntax trick in a way. And
On Sun, Oct 20, 2013 at 5:11 PM, Marijn Haverbeke mari...@gmail.com wrote:
Another problem with this proposal seems that it does away with the
possibility of explicitly grouping a bunch of methods that make up the
implementation of an interface. Implementing interfaces go-style, by
just
On Sun, Oct 20, 2013 at 7:31 PM, Gábor Lehel illiss...@gmail.com wrote:
So I very much agree with Patrick. Some aspects of this proposal are
attractive, but it breaks some essential properties of the way methods
currently work (and probably can't be adjusted to work around that
without losing
Isn't #1 basically what argument-dependent lookup (Koenig lookup) is trying to
do in C++? I'm very nervous of going down that road.
Patrick
Matthieu Monrocq matthieu.monr...@gmail.com wrote:
It seems to me that maybe there are several concepts/changes that are
discussed at once, and it would be
What would happen if two types defined a method called, say, foo, and the
importing module glob imported them both?
Patrick
Gábor Lehel illiss...@gmail.com wrote:
On Sun, Oct 20, 2013 at 7:31 PM, Gábor Lehel illiss...@gmail.com
wrote:
So I very much agree with Patrick. Some aspects of this
On Sun, Oct 20, 2013 at 8:01 PM, Patrick Walton pwal...@mozilla.com wrote:
What would happen if two types defined a method called, say, foo, and
the importing module glob imported them both?
Here's the part where I have to say that I'm not intimately familiar with
how Rust's existing method
But then it seems strange to require that the methods be imported at all, if
you're going to do single-dispatch type-based resolution on them anyway.
What we could do, perhaps, is add a third source of methods that the dot
operator searches: functions in scope. This would allow methods to be
On Sun, Oct 20, 2013 at 7:31 PM, Gábor Lehel illiss...@gmail.com wrote:
On Sun, Oct 20, 2013 at 5:11 PM, Marijn Haverbeke mari...@gmail.comwrote:
Another problem with this proposal seems that it does away with the
possibility of explicitly grouping a bunch of methods that make up the
On Sun, Oct 20, 2013 at 8:16 PM, Patrick Walton pwal...@mozilla.com wrote:
But then it seems strange to require that the methods be imported at all,
if you're going to do single-dispatch type-based resolution on them anyway.
Well, it would do type-based resolution based on the methods which
simplification
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary7823106168118235853==
--===7823106168118235853==
Content-Type: multipart/alternative;
boundary=4SVSQE8L3ECYN7Z8RACUF07S828YYG
--4SVSQE8L3ECYN7Z8RACUF07S828YYG
Content-Type: text/plain;
On Sat, Oct 19, 2013 at 8:14 AM, Brian Anderson bander...@mozilla.com wrote:
This year, the Rust and Servo projects are participating in the GNOME
Outreach Program for Women (OPW).
Nice to hear.
Nick
___
Rust-dev mailing list
Rust-dev@mozilla.org
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.
I'm not convinced that this is solving a
Hi,
I was reading an issue on Rust repo about functions default arguments
and keyword arguments, and I saw that it didn't advanced yet.
So, after asking in #rust IRC chan, I decided to create a pad about this
issue to let people talk and arguing about this feature request.
The goal of this pad
+1 to the Etherpad idea. It's a lot easier to collaborate there than a GitHub
issue.
Patrick
Guillaume HERVIER eperso.m...@gmail.com wrote:
Hi,
I was reading an issue on Rust repo about functions default arguments
and keyword arguments, and I saw that it didn't advanced yet.
So, after asking
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
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
21 matches
Mail list logo
