On Sun, Oct 20, 2013 at 5:28 AM, Gábor Lehel illiss...@gmail.com wrote:
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
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
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
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
Interesting idea; in that case, one could string together any series of
functions - basically, `.` would become the equivalent of `|` (or whatever
other name you want to call it). That is, instead of writing
`baz(bar(foo(x), y), z)` one could write `foo(x).bar(y).baz(z)`. This would
make it easier
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
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,
On Sat, Oct 19, 2013 at 1:52 PM, Patrick Walton pwal...@mozilla.com wrote:
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
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
On Sat, Oct 19, 2013 at 4:35 PM, David Piepgrass qwertie...@gmail.comwrote:
In C# it's nice that I can find all the so-called extension methods by
searching for (this .
Aren't `impl`s in Rust somewhat similar to extension methods in C#? For
instance:
trait Doubler {
fn double(self) -
On Saturday, October 19, 2013, Ziad Hatahet wrote:
On Sat, Oct 19, 2013 at 4:35 PM, David Piepgrass
qwertie...@gmail.comjavascript:_e({}, 'cvml', 'qwertie...@gmail.com');
wrote:
In C# it's nice that I can find all the so-called extension methods by
searching for (this .
Aren't `impl`s
24 matches
Mail list logo
