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
Hi, Im actually working on a more detailed version of this proposal myself,
covering more of the problem space (thin pointer, implications, etc).
However, I hadn't yet considered the possibility of remapping the fields,
instead assuming a simple same-name prefix restriction.
Would you mind me
This is great, thanks!
On Thu, Apr 17, 2014 at 9:21 AM, Flaper87 flape...@gmail.com wrote:
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,
On 2014-04-17, at 11:25, Marvin Löbel loebel.mar...@gmail.com wrote:
Would you mind me taking this RFC over and including it into my proposal?
Yes please, by all means. I'm looking forward to your proposal.
But actually I just realized that my proposal is essentially just a syntax
sugar for a
Can someone explain me why the module system maps to the file system in the way
it does? The problem is that you can end up with these modules named mod.rs
instead of the more informative names. If you have the following modules:
foo
foo::lut
bar
bar::lut
...that maps to files and folders as
On Thu, Apr 17, 2014 at 05:39:15PM +0300, Tommi wrote:
...but why not map such modules to files and folders as the following:
foo.rs
foo/lut.rs
bar.rs
bar/lut.rs
...and have each module informatively named.
This used to be our system and we found it very confusing in practice.
Basically
It current can compile, but judging from signatures:
std::task::try is pub fn tryT: Send(f: proc(): Send - T) - ResultT,
~Any:Send
std::result::unwrap on the other hand is implT, E: Show ResultT, E { fn
unwrap(self) - T {...} }
There's no way the error part of result from task::try(...) can
The ~Any type has a special implementation of Show:
https://github.com/mozilla/rust/blob/master/src/libstd/any.rs#L151-L155
I believe it was primarily used in failure messages originally (you
can fail a task with ~Any)
On Thu, Apr 17, 2014 at 8:55 AM, Edward Wang edward.yu.w...@gmail.com wrote:
You can use task::try(...).ok().unwrap() for Results with non-Show error
types.
Steven Fackler
On Thu, Apr 17, 2014 at 8:55 AM, Edward Wang edward.yu.w...@gmail.comwrote:
It current can compile, but judging from signatures:
std::task::try is pub fn tryT: Send(f: proc(): Send - T) - ResultT,
Sublime does this automatically.
On Thu, Apr 17, 2014 at 10:56 AM, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Apr 17, 2014 at 05:39:15PM +0300, Tommi wrote:
...but why not map such modules to files and folders as the following:
foo.rs
foo/lut.rs
bar.rs
bar/lut.rs
...and
Tommi (cc'ing rust-dev)-
I don't know if this is considered an anti-pattern or not, but if you want to
structure your files in the manner you describe, you can do so without
resorting to `#[path=…]`, assuming you're willing to add a bit of boilerplate
to the foo.rs and bar.rs to pull in the
On 04/17/2014 12:21 AM, Flaper87 wrote:
2014-04-17 2:11 GMT+02:00 Alex Crichton a...@crichton.co
mailto: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
On 04/17/2014 07:39 AM, Tommi wrote:
Can someone explain me why the module system maps to the file system in the way
it does? The problem is that you can end up with these modules named mod.rs
instead of the more informative names. If you have the following modules:
foo
foo::lut
bar
bar::lut
Okay, thanks for explaining the reasoning. I think I'll conform to the standard
way of doing things.
On 2014-04-17, at 18:56, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Apr 17, 2014 at 05:39:15PM +0300, Tommi wrote:
...but why not map such modules to files and folders as the following:
Could someone please commit this RFC for me, thank you:
- Start Date: 2014-04-18
- RFC PR #:
- Rust Issue #:
# Summary
I propose the ability to set trait items (i.e. just methods currently) private
as well as public in order to expand the scope of possible use cases of
provided methods (i.e.
15 matches
Mail list logo
