Re: [rust-dev] Removing some autoref magic

On 2013-11-21, at 4:16, Ziad Hatahet wrote: > What about @/Gc<> types then? You could still potentially reuse them. > > -- > Ziad > > > On Wed, Nov 20, 2013 at 5:58 PM, Tommi wrote: > While I'm trying to argue why the proposed solution is not a full solution to > the proposed problem, I don'

Re: [rust-dev] Removing some autoref magic

On Nov 20, 2013, at 6:21 PM, Ziad Hatahet wrote: > On Wed, Nov 20, 2013 at 5:58 PM, Tommi wrote: > Here's why: if you make a call foo(arg) and never use arg after that, then > you don't care if arg gets moved or borrowed. And if you try to use arg > afterwards and foodid in fact move it previo

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 5:58 PM, Tommi wrote: > Here's why: if you make a call foo(arg) and never use arg after that, > then you don't care if arg gets moved or borrowed. And if you try to use > arg afterwards and foo did in fact move it previously, then your IDE is > going to tell you about it b

Re: [rust-dev] Removing some autoref magic

What about @/Gc<> types then? You could still potentially reuse them. -- Ziad On Wed, Nov 20, 2013 at 5:58 PM, Tommi wrote: > While I'm trying to argue why the proposed solution is not a full solution > to the proposed problem, I don't even think that the proposed problem is a > problem. Here'

Re: [rust-dev] Removing some autoref magic

This strikes me as a good point. I think the incongruity this would create between functions and methods -- along with the additional syntactic burden -- could lead to the use of functions feeling second class in some sense. Also, how would static methods be treated? Cheers, Tim On Wed, Nov 20,

Re: [rust-dev] Removing some autoref magic

While I'm trying to argue why the proposed solution is not a full solution to the proposed problem, I don't even think that the proposed problem is a problem. Here's why: if you make a call foo(arg) and never use arg after that, then you don't care if arg gets moved or borrowed. And if you try t

Re: [rust-dev] Removing some autoref magic

On 2013-11-20, at 18:27, Patrick Walton wrote: > On 11/19/13 9:42 PM, Tommi wrote: >> Our problem is that, given let arg: ~A;, seeing only foo(arg) in code >> doesn't tell us whether arg is moved or borrowed. The proposed solution >> is that auto-borrowing in that context would be deprecated and

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 11:23:57AM -0700, David Piepgrass wrote: > I'm wondering something. Have the Rust developers considered the > possibility of using references instead of pointers? It seems to me > that this would eliminate a lot of the need for "autoderef". Now I'm > not well-equipped to tal

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 10:27 AM, Patrick Walton wrote: > On 11/20/13 10:23 AM, David Piepgrass wrote: > > It seems to me that the majority of languages have recognized that >> references are easier to work with than pointers, and not just because you >> can write "foo.f()" instead of "foo->

Re: [rust-dev] Removing some autoref magic

On Nov 20, 2013, at 8:52 AM, Corey Richardson wrote: > I do, and I agree a lot with Niko's arguments from the meeting. I > agree that &* is a bit ugly, but I prefer the ugly syntax to the > ambiguity. I don't find Kevin's argument particularly convincing; > those changes can make your code fail t

Re: [rust-dev] Removing some autoref magic

On 11/20/13 10:23 AM, David Piepgrass wrote: I'm wondering something. Have the Rust developers considered the possibility of using references instead of pointers? It seems to me that this would eliminate a lot of the need for "autoderef". Now I'm not well-equipped to talk about Rust (some of t

Re: [rust-dev] Removing some autoref magic

If the concern is mutability rather than details of the indirection used, then one option would be: let mut a = ~["y"]; push(mut a, b); It would be a bit odd to do: let mut x = 0; incr(mut x); instead of: incr(&mut x); as long as you're keeping a strict pointer vs. value mental model, but par

Re: [rust-dev] Removing some autoref magic

I'm wondering something. Have the Rust developers considered the possibility of using references instead of pointers? It seems to me that this would eliminate a lot of the need for "autoderef". Now I'm not well-equipped to talk about Rust (some of the rules I am totally ignorant about, e.g. I know

Re: [rust-dev] Removing some autoref magic

> > > > may mutate `a`, while: > > > > let mut a = ~["y"]; > > push(a, b); > > > > will *not* mutate `a`. Do others have the same expectation? > > > But isn't there a missing context there ? That 'a' does not necessarily have to be mutable globally ? But could be constrained... only in t

Re: [rust-dev] Removing some autoref magic

One caveat: this e-mail made it sound as if the proposal were universally favored at the meeting, but I at least feel conflicted, though I may not have that clear. I started writing a response but it got long, so I moved it to a blog post: http://smallcultfollowing.com/babysteps/blog/2013/11/20/pa

Re: [rust-dev] Removing some autoref magic

Obligatory link to Niko's blog post on this topic: http://smallcultfollowing.com/babysteps/blog/2013/11/20/parameter-coercion-in-rust/ I do agree that explicitness is nice, but too much noise will harm readability just as much as magic does. It also doesn't help that the `&*` operator is a bit mi

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 11:37 AM, Patrick Walton wrote: > On 11/20/13 5:05 AM, Sanghyeon Seo wrote: >> >> I am against this proposal. As I understand, we will still keep >> autoref, autoborrow, etc. in method calls. So I don't think inconsistency >> argument holds. Neither does local readability a

Re: [rust-dev] Removing some autoref magic

On 11/20/13 5:05 AM, Sanghyeon Seo wrote: I am against this proposal. As I understand, we will still keep autoref, autoborrow, etc. in method calls. So I don't think inconsistency argument holds. Neither does local readability argument. It is a good point that a true emphasis on consistency bet

Re: [rust-dev] Removing some autoref magic

On 11/20/13 6:25 AM, spir wrote: I like this proposal, because afaik it matches the common use case. Also, it would make things easier to learn, understand, and use, for people not used to move semantics (even less to it as default / implicit case). I do struggle with move; making it explicit wou

Re: [rust-dev] Removing some autoref magic

On 11/20/13 5:51 AM, Bill Myers wrote: Have you considered making deref the default instead and requiring moves to use an explicit "move" keyword? Tried it a year ago. It was incredibly noisy. I don't want to go back to that world. We saw things like: let move x = move foo(move y); Pat

Re: [rust-dev] Removing some autoref magic

On 11/19/13 9:42 PM, Tommi wrote: Our problem is that, given let arg: ~A;, seeing only foo(arg) in code doesn't tell us whether arg is moved or borrowed. The proposed solution is that auto-borrowing in that context would be deprecated and thus would require an explicit borrowing: foo(&*arg). Now,

Re: [rust-dev] Removing some autoref magic

On 11/20/2013 02:51 PM, Bill Myers wrote: Have you considered making deref the default instead and requiring moves to use an explicit "move" keyword? Basically, from this hypothetical syntax to current one: - x => &x - mut x => &mut x - move x => x One could even make the & implicit in paramet

Re: [rust-dev] Removing some autoref magic

Have you considered making deref the default instead and requiring moves to use an explicit "move" keyword? Basically, from this hypothetical syntax to current one: - x => &x - mut x => &mut x - move x => x One could even make the & implicit in parameter types in function declarations unless th

Re: [rust-dev] Removing some autoref magic

First, I am speaking for myself and not my employer. > The current proposal is to remove all autoref except for function > invocations and indexing operations. The method of creating &T from ~T > would be `let foo: &T = foo` or `&*foo`. Vectors and strings can't > currently benefit from the `&*foo

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 6:52 AM, Niko Matsakis wrote: > > I stand by the arguments I made in that post. My experience at least > has been that implicit moves have been much more pleasant to work with > than explicit ones, and the language is simpler as well. I agree, and I think this is one of th

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 12:30:59AM -0800, Vadim wrote: > I found this > postby > Niko, and it seems that at the time everyone agreed that implicit > moving > actually makes things more clear. Why is this different now,

Re: [rust-dev] Removing some autoref magic

On 20 November 2013 02:07, Ziad Hatahet wrote: >> Personally I would prefer if & in Rust worked similar to const T& in c++ > > In that case, you would not be able to tell whether a function argument was > passed by value or by reference. I actually like this feature about Rust (C# > has it too wit

Re: [rust-dev] Removing some autoref magic

I found this postby Niko, and it seems that at the time everyone agreed that implicit moving actually makes things more clear. Why is this different now, only a year later? :-) Ok, but serieosly, I allow that this is

Re: [rust-dev] Removing some autoref magic

On 2013-11-20, at 7:13, Tommi wrote: > Yeah, my claim that it "doesn't buy us anything" stemmed from a misconception > that arg.foo() could move arg, given let arg: ~A; and fn foo(x: ~A) {...}. I > had already forgotten that Rust UFCS was specified differently from D's. To > anyone not follow

Re: [rust-dev] Removing some autoref magic

On 2013-11-20, at 6:24, Patrick Walton wrote: > On 11/19/13 7:43 PM, Tommi wrote: >> I like how your argument nudges this whole discussion a few inches to >> the left. Now we see that disallowing auto-borrowing from regular >> function arguments doesn't buy us anything unless we also disallow it

Re: [rust-dev] Removing some autoref magic

On 11/19/13 7:43 PM, Tommi wrote: I like how your argument nudges this whole discussion a few inches to the left. Now we see that disallowing auto-borrowing from regular function arguments doesn't buy us anything unless we also disallow it from the target of method invocation syntax (dot notation

Re: [rust-dev] Removing some autoref magic

On 2013-11-20, at 1:40, Benjamin Striegel wrote: > If autoref still happens on methods, does this mean that you'd be able to get > around the need to do: > > sort(&mut *foo); > > ...by turning it into a method? > > foo.sort(); I like how your argument nudges this whole discussion a f

Re: [rust-dev] Removing some autoref magic

While i like auto magic eg you could let region analysis work out the pointer type , borrowed pointers etc ,however you need to be very careful . C# uses ref but autoboxing is a major issue , you dont know when the struct is boxed ( there are some places besides the obvious virt call ) and then y

Re: [rust-dev] Removing some autoref magic

If the function is not going to mutate it, I don't really care if it's by-ref or by-value. That's why I said "const T&", not "T&". Well, except for the case when a function caches a reference to something which I later mutate. But borrow checking will prevent that. I would also be totally fi

Re: [rust-dev] Removing some autoref magic

> Personally I would prefer if & in Rust worked similar to const T& in c++ In that case, you would not be able to tell whether a function argument was passed by value or by reference. I actually like this feature about Rust (C# has it too with the `ref` keyword). -- Ziad On Tue, Nov 19, 2013 at

Re: [rust-dev] Removing some autoref magic

So why did Rust adopt auto-moving instead of explicit moving? If the second example had to be written as foo(move a) there would be no confusion. The and the third example should arguably be sort(mut a.as_mut_slice()). Personally I would prefer if & in Rust worked similar to const T& in c++ (i

Re: [rust-dev] Removing some autoref magic

If autoref still happens on methods, does this mean that you'd be able to get around the need to do: sort(&mut *foo); ...by turning it into a method? foo.sort(); On Tue, Nov 19, 2013 at 6:10 PM, Kevin Ballard wrote: > In general, I’m not a fan of &*, and I like auto-borrowing (autore

Re: [rust-dev] Removing some autoref magic

In general, I’m not a fan of &*, and I like auto-borrowing (autoref sounds like it turns T into &T, not ~T into &T). I understand the arguments to get rid of it though. BTW, you said that the current proposal still includes autoref for function invocation. That sounds to me like autoref would s

Re: [rust-dev] Removing some autoref magic

Additionally, we discussed this today at our weekly meeting, and the minutes can be found here: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-11-19#autoderef ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-

[rust-dev] Removing some autoref magic

Hello rust-dev! Everyone's had their fair share of issues with autoref and autoderef, and it's worth considering removing certain portions of it from the compiler. The discussion around this has been rooted in the past, but has recently been brought up as part of https://github.com/mozilla/rust/is