Alex, you are right. I need to rephrase my question. Consider the following:
pub trait T1 {}
pub trait T2 {}
impl T1 for ~T2 {}
pub struct S;
impl T2 for S {}
fn check_bounds(_: U) {}
fn main() {
let x = ~S as ~T2:Send;
check_bounds(x);
}
Should check_bounds fail? It currentl
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. d
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 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
>>
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
On 04/17/2014 12:21 AM, Flaper87 wrote:
2014-04-17 2:11 GMT+02:00 Alex Crichton 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 necessary to explai
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 mod
Sublime does this automatically.
On Thu, Apr 17, 2014 at 10:56 AM, Niko Matsakis 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 have
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 wrote:
> It current can compile, but judging from signatures:
>
> std::task::try is pub fn try(f: proc(): Send -> T) -> Result ~Any:Send>
> std::result::un
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 wrote:
> It current can compile
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.
Ba
It current can compile, but judging from signatures:
std::task::try is pub fn try(f: proc(): Send -> T) -> Result
std::result::unwrap on the other hand is impl Result { fn
unwrap(self) -> T {...} }
There's no way the error part of result from task::try(...) can fulfil Show
so it shouldn't compile
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 su
On 2014-04-17, at 11:25, Marvin Löbel 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 macro producing boiler
This is great, thanks!
On Thu, Apr 17, 2014 at 9:21 AM, Flaper87 wrote:
>
>
>
> 2014-04-17 2:11 GMT+02:00 Alex Crichton :
>
> 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 neces
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 tak
2014-04-17 2:11 GMT+02:00 Alex Crichton :
> 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
16 matches
Mail list logo
