Re: [rust-dev] [ANN] Brooklyn.rs
On Jun 21, 2014 12:46 PM, Steve Klabnik st...@steveklabnik.com wrote: For those of you coming today, my train has been delayed multiple times, so I will be a few minutes late. I'll be wearing a bright red Ruby shirt, because that's funny and also more noticeable. See you all soon! Already here. I'm not wearing a red T-shirt but I've Rust stickers to give away. :) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Brooklyn.rs
2014-06-09 19:24 GMT+02:00 Steve Klabnik st...@steveklabnik.com: Hey all! So, I've moved to NYC, and one of the things I'm gonna miss the most about SF is they Bay Area Rust Meetup... so let's do this! Once my DNS resolves, the site will exist at http://www.brooklyn.rs . Until then, you can check it out at http://steveklabnik.github.io/brooklyn.rs/ TL;DR: The first meeting will be Saturday, June 21, at 1pm. I know weekends are hard for some people, so I plan on moving it to a weekday later, but Saturday hacking is a special thing to me[1] So the first one will be there. No talks, just hacking on some code. Keep it nice and simple at first. I hope to see you all there! 1: http://words.steveklabnik.com/keep-saturdays-sacred ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev I'll be in NYC that day so, count me in! Flavio -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] This Week in Rust (26 April 2014)
2014-04-26 20:46 GMT+02:00 Corey Richardson co...@octayn.net: [snip] # What's cooking on master? 153 pull requests were merged in the last two weeks. ## Breaking Changes - Auto-rooting of `@` [has been removed](https://github.com/mozilla/rust/pull/13559). The exact fallout of this isn't obvious to me, but presumably this makes some uses of `@` not work. The gist of this change is that there's no more special rooting for `@` pointers. Instead, `@`-pointers de-referencing basically follows the same rules as `~`-pointers do. The fallout will likely be that some usages of `@`-pointers may need explicit references to avoid lifetime issues. (See the fallout commits in the PR for more info) Hope this clears things a bit more. [snip] -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust .so that looks like a C .so
2014-04-24 13:20 GMT+02:00 Stéphane Wirtel steph...@wirtel.be: On 24 Apr 2014, at 13:16, Henri Sivonen wrote: The documentation for the FFI seems focused on using C code in a program whose main() is in Rust. Can Rust be used for implementing a shared library that implements a C ABI for use by programs whose main() is not in Rust (i.e. the caller sees a C ABI and doesn't know about Rust)? If yes, can a C program use multiple such libraries so that their Rust runtime bits don't conflict? Is there a tool for generating .h files for C-callable Rust functions and their argument data types? Yes, normally you can create a shared lib with Rust and extern the code with the C convention ( sorry, I don't remember the right name). and via this convention, you can use your Rust lib in Python/Ruby or an other languages. Here's a very tiny and simple example: https://github.com/FlaPer87/rust-asterisk-example Hope it helps, -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Private trait items
2014-04-22 15:45 GMT+02:00 Tommi rusty.ga...@icloud.com: No one? I understand that a part of the reason the RFC process is made so complex is that it filters out idiots like me. But I think this one is a pretty important design choice that Rust is about to get wrong. If the RFC process is complex, then I believe there's something we should probably make easier. The idea is not to filter folks out but to welcome them and make the collaboration process easier for everyone What parts of this process are complex? [0] What problems are you having with GitHub? Have you looked into this guide? [1] [0] https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md [1] https://help.github.com/articles/using-pull-requests Flavio -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Keeping up with Breaking Changes
2014-04-17 2:11 GMT+02:00 Alex Crichton a...@crichton.co: The template which breaking changes will be required to look like is: First, a brief one-line summary of the change Second, take as long as is necessary to explain exactly what the change is, why it's being changed, what it can be replaced with (if applicable) and general guidelines about dealing with the change. In addition to a few paragraphs about the change itself, the literal string [breaking-change] must appear at the end of the commit message in order to indicate that it is a commit that has a breaking change. This will allow filtering commits on this string to only take a look at breaking changes. [breaking-change] Sometimes, the breaking change is split in several commits. I'd recommend to add to the breaking change tag the number of the GH issue (I wanted to propose a change tag but I don't think that will end well). I don't expect breaking changes to happen without a GH issue baking them - or at least, I don't think that should happen. Tagging the last commit of the series should probably be enough but, for completeness, I think they should all be tagged. This will produce a more complete output when `grepping` for breaking changes. To get a log of breaking changes, you can use git-log: git log --grep breaking-change # Exclude bors merge commits git log --grep breaking-change --no-merges # Usage of #[deprecated] In addition to a stricter policy around commit messages, we're going to start encouraging more aggressive use of the #[deprecated] attribute to help transitioning code. A good example of this recently is when the `shuffle_mut` function was renamed to `shuffle`. The original function had an attribute that looked like: #[deprecated = function renamed to `shuffle`] We aren't yet going to require that the old function retain its functionality, it is acceptable to replace it with a fail!()-ing stub for now. The compilation warning should be a good enough indicator about what needs to be changed. The deprecated functions themselves aren't expected to stick around for all eternity. By 1.0 we will clean out all #[deprecated] functionality, and before then we'll likely leave in #[deprecated] functions for about a month or so. I think we should retain the previous functionality. Since it's already there, I don't think it will be of any harm (in most of the cases). Also, I think it'd be good to keep the deprecated function for at least 1 release. I believe this is a good practice and gives users of that function enough time to migrate. This obviously doesn't make much sense if we replace the functionality with a `fail` # Be on the lookout! With these two guidelines in place, we hope to ease the pain of upgrading through versions of rust while it's still under rapid development. Reviewers, be sure to keep an eye out for breaking changes in the future and make sure that the that these measures are followed! I'm really happy to see this happening! -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Updated RFC process
` with the RFCs indexed and allow people to navigate active, rejected and completed RFCs from there. -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Improving our patch review and approval process (Hopefully)
2014-02-20 0:46 GMT+01:00 Ben Noordhuis i...@bnoordhuis.nl: On Wed, Feb 19, 2014 at 11:53 PM, Alex Crichton a...@crichton.co wrote: Currently, all patches are being tested after they are approved. However, I think it would be of great benefit for contributors - and reviewers - to test patches before and after they're approved. I would personally love to explore using Travis-CI for this. I think this is almost exactly what travis was built for. That being said, there's no way that travis could handle a full `make check` for rust. However, perhaps travis could handle `make check-stage0-lite` (not that this rule exists yet). I think we would have to figure out how to avoid building LLVM, but beyond that we *should* be able to run a bunch of stage0 tests and optimistically print out the results of the PR. This obviously won't catch many classes of bugs, but perhaps it would be good enough for a preemptive check. The best part about this is that it's almost 0 overhead of automation for us because travis would handle all of it. I enabled travis in my Rust fork and added a `make tidy` job[0]. If we can come up with what `check-stage0-lite` should actually do, I think we could try to use travis until the testing infrastructure grows and we'll be able to run this in our buildbot. $0.02 from the node.js and libuv camp: we have used Travis in the past but there were so many spurious test failures (with no way to debug them) that we moved to dedicated Jenkins instances. In my experience, anything involving I/O is hit and miss with Travis. Agreed, this sounds like a very likely scenario, that's why I didn't recommended it to begin with. However, I guess for things like `tidy` checks it should work fine. [0] https://travis-ci.org/FlaPer87/rust/builds/19245016 -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Improving our patch review and approval process (Hopefully)
Hi all, I'd like to share some thoughts with regard to our current test and approval process. Let me break this thoughts into 2 separate sections: 1. Testing: Currently, all patches are being tested after they are approved. However, I think it would be of great benefit for contributors - and reviewers - to test patches before and after they're approved. Testing the patches before approval will allow folks proposing patches - although they're expected to test the patches before submitting them - and reviewers to know that the patch is indeed mergeable. Furthermore, it will help spotting corner cases, regressions that would benefit from a good discussion while the PR is hot. I think we don't need to run all jobs, perhaps just Windows, OSx and Linux should be enough for a first test phase. It would also be nice to run lint checks, stability checks etc. IIRC, GH's API should allow us to notify this checks failures. 2. Approval Process I'm very happy about how patches are reviewed. The time a patch waits before receiving the first comment is almost 0 seconds and we are spread in many patches. If we think someone else should take a look at some patch, we always make sure to mention that person. I think the language would benefit from a more strict approval process. For example, requiring 2 r+ from 2 different reviewers instead of 1. This might seem a bit drastic now, however as the number of contributors grows, this will help with making sure that patches are reviewed at least by 2 core reviewers and they get enough attention. I think both of these points are very important now that we're moving towards 1.0 and the community keeps growing. Thoughts? Feedback? -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Improving our patch review and approval process (Hopefully)
2014-02-19 22:48 GMT+01:00 Kevin Ballard ke...@sb.org: On Feb 19, 2014, at 12:28 PM, Corey Richardson co...@octayn.net wrote: This is a pretty bad idea, allowing *arbitrary unreviewed anything* to run on the buildbots. All it needs to do is remove the contents of its home directory to put the builder out of commission, afaik. It'd definitely be nice to have it run tidy etc first, but there needs to be a check tidy or any of its deps. This is a very good point. And it could do more than that too. It could use a local privilege escalation exploit (if one exists) to take over the entire machine. Or it could start sending out spam emails. Or maybe it starts mining bit coins. Code should not be run that is not at least read first by a reviewer. I should have expanded more that thought. I'm not expecting this to be doable with the way our jobs now. This would require things like: * Running jobs isolated boxes / VMs * Set limits on the execution time * Remove any internet connection in the box (?) * [add here whatever would make this more secure] I'm not proposing something new here. This is something that I've seen done in several communities (OpenStack's is one of those) and as mentioned in my previous emails, there's some benefit behind this. -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] What form should the official Rust binary installers for Unixes take?
2014-02-12 2:04 GMT+01:00 Daniel Micay danielmi...@gmail.com: On Tue, Feb 11, 2014 at 7:58 PM, Brian Anderson bander...@mozilla.com wrote: On 02/11/2014 01:01 AM, Tom Lee wrote: Hey Brian, Not sure I understand the last paragraph of your email (do you or do you not want to encourage distro-specific installation? :)) I'm still not sure. I want people to be able to install Rust easily and I want those sources to be reliable. I don't think Rust should endorse third party binary builds, but official distribution packages aren't third party as the distribution is already trusted by the user. There's some value in not being opinionated when it comes to supporting distros. I think Rust should have 1 official distribution package (binaries) and let distros' package maintainers take care of the rest. Distro users will most likely prefer and tust their own package manager / maintainer. what is important, though, is that Rust doesn't block distros on building their packages. This has been raised in this thread already, though. Cheers, Fla. -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Code review checklist
2014/1/22 Brian Anderson bander...@mozilla.com Thanks. This is a good idea. I added it to the Notes wiki page now! Hope it helps! FF On 01/19/2014 04:52 AM, Flaper87 wrote: Hey, I've been doing reviews for a bit and I just realized we, as community, don't have a review checklist that all reviewers should go through. I thought that it could be useful to have a wiki page describing the review proces for newcomers and people willing to contribute with reviews. I wrote some points here[0] based on what I've seen. I also added a section for non-core reviewers (people w/o r+ powers). In this section I just added 1 item in order for these group of folks (which I'm part of) to give their blessing to the patches they've reviewed. This will welcome more reviewes at the cost of adding more noise to the PR. Any comments are welcome. Also, it's a wiki page so feel free to improve it. I haven't linked it to the 'Notes for developers' page because I'd like it to be reviewed first. [0] https://github.com/mozilla/rust/wiki/Note-code-review FF -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Code review checklist
Hey, I've been doing reviews for a bit and I just realized we, as community, don't have a review checklist that all reviewers should go through. I thought that it could be useful to have a wiki page describing the review proces for newcomers and people willing to contribute with reviews. I wrote some points here[0] based on what I've seen. I also added a section for non-core reviewers (people w/o r+ powers). In this section I just added 1 item in order for these group of folks (which I'm part of) to give their blessing to the patches they've reviewed. This will welcome more reviewes at the cost of adding more noise to the PR. Any comments are welcome. Also, it's a wiki page so feel free to improve it. I haven't linked it to the 'Notes for developers' page because I'd like it to be reviewed first. [0] https://github.com/mozilla/rust/wiki/Note-code-review FF -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] sticker
2014/1/14 Gaetan gae...@xeberon.net Just came accross this good presentation: http://www.youtube.com/watch?v=gfCtbGiHcg0 A question poped into my head: where could I find rust stickers ? I was wondering the same thing! I love stickers and I definitely want a Rust sticker :D -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Configuration files library for Rust
Hi Guys, I was looking around and I couldn't find a config file parser library for Rust. Getopt support seems to be pretty complete and stable, which would make the development of such library easier. Since I've some experience on this area, I thought about doing some work on it for Rust. My current plan is to do something along the lines of oslo.config[0] - which I've been contributing to - and take advantage of the existing getopt module, just as we do in oslo.config. The config file format parsed by oslo.config follows the INI[1] files format but with some changes to support list options and other types. One of the advantages of this library is that the config options registration is explicit and simple. However, before starting to work on this, I'd like to know what folks on this list think about the library, if there's been some work on this area that I'm not aware of, what the preferences are, etc. Cheers, FF [0] https://github.com/openstack/oslo.config [1] http://en.wikipedia.org/wiki/INI_file -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Configuration files library for Rust
2014/1/4 Corey Richardson co...@octayn.net oslo.config looks decent. On some projects I've worked on, we started out using INI files but found them severely lacking once we wanted to extend the options. We ended up using libconfig[0], which I think is an excellent library. In multibuilder[1], we use extra::serialize to load a config directly into the struct we'll be using. It's super convenient, but a bit unfortunate in that it's impossible to make a field truly optional (OptionT requires the field to be null, iirc). [0] http://www.hyperrealm.com/libconfig/ [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 I'm also considering to have support for several parsers. It should be pretty simple / straightforward to do so. We could have a default parser based on INI files and then allow people to specify a different parser in case INI files are not what they want to use. I'll dive into libconfig and pick things from there as well. Also, I agree INI files could be a bit limited, which is why we ended up having our own INI parser in oslo.config. Thoughts? FF On Sat, Jan 4, 2014 at 9:01 AM, Flaper87 flape...@gmail.com wrote: Hi Guys, I was looking around and I couldn't find a config file parser library for Rust. Getopt support seems to be pretty complete and stable, which would make the development of such library easier. Since I've some experience on this area, I thought about doing some work on it for Rust. My current plan is to do something along the lines of oslo.config[0] - which I've been contributing to - and take advantage of the existing getopt module, just as we do in oslo.config. The config file format parsed by oslo.config follows the INI[1] files format but with some changes to support list options and other types. One of the advantages of this library is that the config options registration is explicit and simple. However, before starting to work on this, I'd like to know what folks on this list think about the library, if there's been some work on this area that I'm not aware of, what the preferences are, etc. Cheers, FF [0] https://github.com/openstack/oslo.config [1] http://en.wikipedia.org/wiki/INI_file -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Thoughts on the Rust Roadmap
2013/12/30 Armin Ronacher armin.ronac...@active-4.com Hi, I am not using Rust nearly as much as I wish I could, but I absolutely love playing around with it and seeing where it's heading. I think all things considered the language is going exactly where I want it to go. It's for the most part very pleasant to work with and it's getting better and better. But there is so much more work needed. Not just because the language is lacking things that are needed, but because many users of the language are not sure yet how to use it. The compiler and the standard library use widely different patterns and so do libraries written by other people. There are half a dozen ways to deal with errors now, there are different patterns of how to deal with Options and Results. There are vastly different ways to design whole APIs, how to deal with the traits and so forth. There are different patterns to interface with native libraries, different patterns to interface with task local data etc. The introduction of external iterators (which I found the most exciting change of the language) has shown a whole new area of shortcomings in the current feature set (lack decltype when returning composed iterators for instance, non sendable closures etc.). Not only did it show shortcomings in lacking features, it also put some emphasis on new patterns that are not widely deployed in the stdlib yet. I really hope there is left enough time to actually continue evolving the language and libraries before freezing anything. Especially now that the split into libnative and libgreen is happening it will be important to stay flexible for adjusting the design of the standard library so that we don't end up with two vastly different ways to do IO. It does not take a genius to realize that there is already some tension among developers with regards to where the language should be going, and at what pace. As an outside observer that is very much in love with Rust and where it's heading, I want to voice the wish that there will be enough time to continue evolving the language before racing to a 1.0 release. Especially now that there is a lot of interest in Rust and similar languages I believe this is necessary. As it stands right now, there are too many things that make Rust still frustrating because you program yourself into a corner. TL;DR: please don't rush a 1.0 release. FWIW, I couldn't agree more with Armin. There's a lot of excitement about Rust right now. The language has evolved a lot lately and some folks can't wait to get their hands on it. However, it's really important not to rush it and make sure the language is not just what people expect. The language has to reach a point were it's enough features for people to use it and contribute back. It's also important to make sure the language reaches the point where it's possible to keep adding / removing things without much pain. Cheers, FF -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Rust for real: Learning Rust by example
Hi Guys, I'm writing this email in the hope of finding some help from you. I recently started this project[0] into which I'll be adding examples of Rust's internal modules - starting from std and then extra - as small programs that can be compiled and ran independently. As for now, there are 2 examples for tasks already. If any of you feels confident enough with any of Rusts modules and wants to write examples - with docstrings and README explaining what's happening - please, feel free to send PR. I created a dir for task's examples into which I put 2 rust files -I'll add more later - with contextualized examples. The first is a simple example of how to use tasks and the second shows how to use nested tasks. I'm planning to add another for inter tasks communications and another for tasks control - supervised, unlinked, poisoning tasks, etc. I think this structure would work well for other modules as well. I'm also planning to add support for rustpkg and let it build the whole thing if someone wants to do that. If you have any better idea, suggestion please, share. Cheers, FF [0] https://github.com/FlaPer87/rust-for-real -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] lib: Is anybody working on the datetime library?
2013/9/13 Luis de Bethencourt l...@debethencourt.com Cool! Great and awesome feedback. The summary is that Joda-Time is what we should aspire to have. My goal is to first cover the most common use cases, and as Corey says, easy to use correctly. After that I can start considering the corner cases like bya and mya. Which sound very fun and interesting, but not high priority. Hopefully by then I won't be too consumed by the question of what is Time. Another thing that I'd like to see there is a good handling of TZs. Many datetime libraries got that wrong. Here's a blog post Armin wrote that may be helpful. http://lucumr.pocoo.org/2011/7/15/eppur-si-muove/ Thanks for taking care of this. FF -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mozilla using Go
2013/9/1 Corey Richardson co...@octayn.net IMO Rust is very applicable as a general purpose language, perhaps moreso than C++. I agree with the above! I don't see Rust being bound to a specific area, I think it can be used in many different types of applications. -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Doc comment conventions + straw poll
2013/8/27 Jeffery Olson olson.jeff...@gmail.com I like ///, although I would like to standardize on comments before/after the method declaration. I'm in favor of having it in the function's body. -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Augmented assignment
2013/8/25 Armin Ronacher armin.ronac...@active-4.com Hi, On 23/08/2013 19:36, Graydon Hoare wrote: Could you say more (perhaps more constructively)? I believe we have every intention to support these sorts of overloads longer-term; we removed the previous support only because it wasn't done terribly well. I think augmented assignments in Python are fine, but they do have some edge cases. The most famous one (as this is generally brought up as Python WTF on various parts of the interwebs) is the one where a mutable element within an immutable structure is modified: a = ([42],) a[0] += [23] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment a ([42, 23],) The reason for this is that `a[0] += [23]` expands to `type(a[0]).__iadd__(a[0], [23])` but afterwards a[0] is overridden with a[0]. Aside from that I believe += and friends are just fine. Some people raised concern that `a = a + [2]` makes a new list but `a += [2]` modifies a list in place, but I think that is pretty obvious from looking at the code. I also think Python's argumented assignments are fine and both a += b vs a + b should behave differently. I personally read a += b as an atomic, thread-safe operation whereas a + b isn't and I beleive that's the way it shoud be. Expanding a += b to a + b doesn't sound right to me. Anyway, that's my $0.02. FF -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Augmented assignment
2013/8/26 Flaper87 flape...@gmail.com argumented augmented* T_T -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Augmented assignment
2013/8/26 Daniel Micay danielmi...@gmail.com On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 flape...@gmail.com wrote: I also think Python's argumented assignments are fine and both a += b vs a + b should behave differently. I personally read a += b as an atomic, thread-safe operation whereas a + b isn't and I beleive that's the way it shoud be. Expanding a += b to a + b doesn't sound right to me. Anyway, that's my $0.02. FF In C/C++/Python/Rust, `+=` isn't an atomic operation. T_T, I knew that, bad wording from my side. Although, in the safe subset of Rust code there's no way to race on mutable data due to the inability to share it without locking. I believe this is good, I wasn't sure though. FF -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
