On 17 Sep 2014, at 23:33, Sean McArthur wrote:
> On Wed, Sep 17, 2014 at 2:26 PM, Evan Davis wrote:
>
> The problem is that you're trying to use a trait as a type.
>
> That shouldn't be a problem. You can use a `&mut Trait`, and you'll get
> dynamic dispatch.
You cannot mix dynamic dispatch
Philppe (cc’ing rust-dev)-
Hi! I think that we are currently encouraging users to post questions about
using the language (or tools, etc) to StackOverflow, using the “rust” tag so
that the community can find them easily.
http://stackoverflow.com/questions/tagged/rust
You can see Brian’s recen
T{
> match settings.get(&key) {
> MyBool(x) => x,
> MyStr(x) => x,
> MyInt(x) => x
> }
> }
>
> But I don't know how to make this work.
>
> Thanks.
>
>
>
> On Tue, Jul 22, 2014 at 4:55 PM, Felix S. Klock
Aravinda (cc’ing rust-dev)-
You didn’t show us exactly what you had tried to do to get your code to work,
nor did you really describe what it is you want here.
E.g. you seem to want `get_value(MyBool(true))` to return a boolean, but since
`MyBool` belongs to the `MyTypes` enum, that implies tha
Note that we are well aware that the issue Christoph mentioned is a wart for
some uses of traits. E.g. some trait implementors really would like to be told
when they missed a method because it has a default implementation already.
One way to resolve this would be a lint; that has been previousl
Gabor (cc’ing rust-dev)-
I have filed an issue to track incorporating the answers to these questions
into the RFC process documentation.
https://github.com/rust-lang/rfcs/issues/121
Here is some of my opinionated answers to the questions:
1. When an RFC PR is merged as accepted into the repo
Michael (cc'ing rust-dev)-
On 22 May 2014, at 16:32, Michael Woerister wrote:
> Lately I've been thinking that it might be nice if one could omit the
> lifetimes from the list of generic parameters, as in:
>
> fn foo(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint)
>
> instead of
>
> fn foo
Tommi (cc'ing rust-dev)-
I recommend you make a small fake github repository of your own, and learn the
github workflow directly by forking that (perhaps with a separate fresh dummy
github user account).
I am not being facetious; I did a lot of that when I was first getting my
bearings using g
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
On 19/02/2014 21:12, Flaper87 wrote:
2. 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 rev
Martin (cc'ing rust-dev)-
I recommend you file a fresh bug with a transcript of your own build
attempt.
I infer you are pointing us to issue #11162 because of some similarity
in the log output you see between that and your own build issue, but
issue #11162 is fundamentally related to a local
, Rust is incompatible with dlopen()?
Nathan Myers
On 12/19/2013 03:03 AM, Felix S. Klock II wrote:
rust-dev-
From reading the article, I thought the point was that a universal
server could be deployed and initiated before the actual service it
would offer had actually been *written*.
I agree with
rust-dev-
From reading the article, I thought the point was that a universal
server could be deployed and initiated before the actual service it
would offer had actually been *written*.
I agree with Kevin that the exercise would be pretty much pointless for
Rust, unless you enjoy writing int
Gaetan (cc'ing rust-dev)-
On 18/12/2013 09:48, Gaetan wrote:
but I wouldn't understand why the 'mod' keyword would stay
Because a Rust module is not the same thing as a crate.
Changes to the syntax for linking to an external crate is orthogonal to
the concept of a module. So as long as we wa
On 13/12/2013 12:53, spir wrote:
I think this is a good possibility, make the module/crate organisation
mirror the filesystem (or the opposite):
* 1 module = 1 file of code
* 1 package = 1 dir
This may be limiting at times, possibility one may want multi-module
files and multi-file modules.
Ye
rust-dev-
In general, we need to ensure that for an expression ` as
` that any borrowed pointers in the type of are not
obscured [1] by the cast.
A collection of conditions sufficient to enforce this are listed in a
comment in librustc/middle/kind.rs that I think is apropos here:
https:/
First off, the topic of rustc slowness and long bootstrap times has
indeed been discussed many times. If you have not yet tried skimming
the archives, I recommend doing so, e.g. via
http://lmgtfy.com/?q=+site%3Amail.mozilla.org+rust+crate+compilation+speed
(I provide a (surely incomplete) lis
On 22/11/2013 19:32, Brian Anderson wrote:
On 11/21/2013 08:53 PM, Patrick Walton wrote:
There are several issues in the backwards-compatible milestone
related to Unicode identifiers:
#4928: XID_Start/XID_Continue might not be correct
#2253: Do NKFC normalization in lexer
Given the extreme la
Andres (cc'ing rust-dev)-
An initial question, since I'm not clear on one thing:
What is your goal in proposing this change?
That is, is your primary concern that you dislike writing either method
invocations or method definitions? Or are you concerned about the
ability of the compiler to op
turing-completeness proofs of C++ templates. Does that mean rust
generics are not turing complete?
Gokcehan
On Tue, Sep 17, 2013 at 3:28 PM, Felix S. Klock II
mailto:pnkfe...@mozilla.com>> wrote:
Gokcehan-
My understanding is that C++, due to its policy of SFINAE [1],
usual
Gokcehan-
My understanding is that C++, due to its policy of SFINAE [1], usually
provides error feedback after the template has been fully instantiated
and the fully instantiated version fails to compile. This can lead to
hard to debug compile-time failures.
Good compilers can help with diss
Carl, David (cc'ing rust-dev)_
Note that #6396 is about the 'self lifetime.
That may or may not be related to the rustc assertion failure that David
mentions in one of his comments, but I think the bulk of his example
does not use lifetimes at all. (So I'm assuming that his main issues
about
Lindsey (cc'ing rust-dev)-
Its not due to your changes. These are problems that are in master that
for some reasons bors has not caught:
Issue #9127: debug no-optimize make check yields three failures
https://github.com/mozilla/rust/issues/9127
Cheers,
-Felix
On 12/09/2013 06:17, Lindsey K
Bill (cc'ing rust-dev)-
[Executive summary: the provided proposal needs further work.]
I do not know which discussion of data sort refinements you had been
reading; I would have liked context about where you were coming from. I
assume it was either Niko's blog post [1] or issue #1679 [2], but
On 16/07/2013 19:52, Svetoslav Neykov wrote:
On 15.07.13 23:37, Patrick Walton wrote:
>On 7/14/13 1:04 PM, Svetoslav Neykov wrote:
>> ·"unsafe" is not a normal block and doesn't return a value, can't be
>> used as an expression. This made it impossible to wrap the unsafe casts
>> from fixed
On 11/07/2013 13:30, Felix S. Klock II wrote:
On 10/07/2013 22:04, Graydon Hoare wrote:
I assume you've read this:
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-8.pdf
This is also relevant, I think (and more recent):
Antony L. Hosking. 2006. Portable, mostly-concurrent, mostly-co
On 10/07/2013 22:04, Graydon Hoare wrote:
On 13-07-10 11:32 AM, Patrick Walton wrote:
I've been thinking about what will be needed to support incremental and
generational GC in Rust. To be clear, I don't think we should block on
it now, but we should not make it unduly difficult for us to imple
Rémi (cc'ing Philipp and rust-dev list)-
We track bugs, work-items, and (some) feature requests here:
https://github.com/mozilla/rust/issues
Cheers,
-Felix
On 25/06/2013 12:18, Rémi Fontan wrote:
good to know. should I be reporting the bug to some sort of
bug-report-system?
Rémi
On Mon,
On 01/06/2013 06:10, Brian Anderson wrote:
On 05/31/2013 01:44 AM, Sanghyeon Seo wrote:
Is it actually possible to use new I/O error handling at the moment?
It seems to me that
it is not possible to get at std::rt::io::io_error at all, because
conditions are private and
do not work cross-crate
On 30/05/2013 05:15, James Miller wrote:
This meant that a fairly simple, standard pass, was being called on over 100x
more code than it
needed to be. If you want to know why a full build takes so long, there is why.
Since I've been curious about the build times this week, I thought I'd
experim
Patrick (cc'ing rust-dev)-
Between the two options Patrick presented, my vote is for bifurcating
the grammar into irrefutable and refutable variants. I like having one
operator to denote binding (even if it also sometimes means mutation).
However, my (potentially-wrong) intuition is that the
On 26/04/2013 17:22, Alex Bradbury wrote:
On 26 April 2013 16:15, Erik S wrote:
For how rarely used "continue" is, four extra characters don't much matter.
The time savings from not having to check the documentation to confirm what
the keyword is will outweigh four characters of typing.
Indeed
On 25/04/2013 18:12, Graydon Hoare wrote:
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
framework we retarget it to.
I'm a fan of this choice too, if only because the simplest efficient
parser-generators and/or parse
Alexander-
What are you suggesting would be the semantics for a Shared -> Owned
conversion?
Just think about it in the the abstract for a moment: If X and Y are
both sharing a reference to a @Pizza, and X decides it wants to hand
the pizza to a customer who is expecting a ~Pizza, what is X s
The team had some discussions recently regarding associated items. In
Vancouver I outlined a small change to the grammar that might solve a
lot of problems.
I have written up the proposal here, with lots of gory background:
http://blog.pnkfx.org/blog/2013/04/22/designing-syntax-for-associated-
Artelia (cc'ing rust-dev)-
FYI: There is no '-g' flag, at least not in Rust 0.6. According to the
#rust IRC channel, the correct flag is now "-Z debug-info"
From the #rust IRC channel:
http://irclog.gr/#show/irc.mozilla.org/rust/444262
Cheers,
-Felix
On 08/04/2013 14:45, Tim Chevalier wro
John (cc'ing rust-dev)-
You can still use the module in other contexts.
pub fn baz() {
mod z {
pub fn f () -> int { 19 }
}
fn g() -> int { use z; z::f() }
g();
}
Cheers,
-Felix
On 06/04/2013 03:50, John Clements wrote:
Our grammar currently
Cool, John beat me to the punch and posted a grammar to a repository!
(And better still, John's grammar looks way more complete than my own.)
I went ahead and shoved my version of Rust.g4 into a branch on a fork
of your repo, so that people can skim and compare the approaches.
(E.g. the use o
I haven't been thrilled with the `mod.rs` convention (because my emacs
buffers all have the same name)
At this point this probably deserves an entry on the wiki or somewhere:
https://www.google.com/search?q=emacs+uniquify
I strongly recommend changing Emacs's default setting for this.
Cheers
Ranvijay (cc'ing rust-dev)-
Since you put your source code in the file c/c.rs, that code belongs to
a module named `c` *inside* of the `c` module you have already put into
your orig.rs crate.
You can see the "git diff" invocation in the transcript below to see how
I fixed your code.
Cheers
On Fri Feb 1 19:13:03 2013, Graydon Hoare wrote:
(they act as sequence-points for make, since it cannot easily guess
the actual hash-based output filenames of the libraries)
I was idly wondering about those hashy filenames: Is the long term plan
to continue to encoding hashes into the filenam
41 matches
Mail list logo
