3 ms·

Thank you for detailed explanation. Any language has some magic. Some languages have too much of magic (like Ruby) and I hope Rust will no go this way. But wh

Thank you for detailed explanation. Any language has some magic. Some languages have too much of magic (like Ruby) and I hope Rust will no go this way. But when magic is about to save couple of lines - I think it's ok, I'm with authors of Java,C#,etc in this term. I prefer to call it syntactic sugar, and to be fair, Rust have examples of such sugar. So in my opinion "sugared" (or magic) "this" keyword inside of method body is more optimal way to send receiver to method - it allows programmer to save lines of needed closures boilerplate.

Manishearth 11y ago
When you make a decision to include some magic, you have to look at the overall milieu of how it can be used and abused, not just the specific use case that it makes awesome. It may "save a couple of lines" but that's not all it does. As far as auto-closureifying methods, you might have a lot of people doing things like `let x = vec.len` and getting confusing errors when trying to use `x`, and other errors due to the implicit moving or borrowing of `vec`. Currently when you make such mistakes (which is common) the compiler tells you exactly how to fix it because taking the value of a method is illegal. If this was legal, it may cause errors further down the line which are not clearly tied to this and you can't have reasonable error messages. Additionally there's no way to specify this moving or borrowing, so an arbitrary choice has to be made, which would be implicit and opaque. Explicit closuring is just a few more characters and not a bad price to pay for avoiding this class of errors. The reason we have explicit `self` (which again, is different from the above and completely orthogonal to the Iron issue) is due to ownership/borrowing again. You want to be able to specify how a method takes its receiver (self/&self/&mut self/Box<Self>). It could be done via extra syntax but that gets uglier, really, and in a language like rust where ownership is important, you don't want ownership implications to be kludgy and confusing. Having a syntax which mirrors argument syntax is really clearer.
- EugeneOZ 11y ago
  > but that gets uglier, really is an argument. Maybe I just can't imagine how ugly it would look without "self" argument. Thank you for explanation. At this point I almost agree with you. Well, I agree, but still can't say "oh, I love that closures boilerplate!" :)
  - Manishearth 11y ago
    Again, the self thing and the closure thing are completely orthogonal. Unrelated. Each sugar could exist independently of the other.

Manishearth 11y ago

When you make a decision to include some magic, you have to look at the overall milieu of how it can be used and abused, not just the specific use case that it makes awesome. It may "save a couple of lines" but that's not all it does. As far as auto-closureifying methods, you might have a lot of people doing things like `let x = vec.len` and getting confusing errors when trying to use `x`, and other errors due to the implicit moving or borrowing of `vec`. Currently when you make such mistakes (which is common) the compiler tells you exactly how to fix it because taking the value of a method is illegal. If this was legal, it may cause errors further down the line which are not clearly tied to this and you can't have reasonable error messages. Additionally there's no way to specify this moving or borrowing, so an arbitrary choice has to be made, which would be implicit and opaque. Explicit closuring is just a few more characters and not a bad price to pay for avoiding this class of errors. The reason we have explicit `self` (which again, is different from the above and completely orthogonal to the Iron issue) is due to ownership/borrowing again. You want to be able to specify how a method takes its receiver (self/&self/&mut self/Box<Self>). It could be done via extra syntax but that gets uglier, really, and in a language like rust where ownership is important, you don't want ownership implications to be kludgy and confusing. Having a syntax which mirrors argument syntax is really clearer.

EugeneOZ 11y ago
> but that gets uglier, really is an argument. Maybe I just can't imagine how ugly it would look without "self" argument. Thank you for explanation. At this point I almost agree with you. Well, I agree, but still can't say "oh, I love that closures boilerplate!" :)
- Manishearth 11y ago
  Again, the self thing and the closure thing are completely orthogonal. Unrelated. Each sugar could exist independently of the other.