Hi,
Am 02.01.2014 um 07:18 schrieb Patrick Walton :
>
>
> And that's just a simple example: start throwing in existential types like
> traits and it becomes clear that you really can't tell from the program where
> mutation could possibly happen, because the types are hiding mutability from
>
Hi,
Am 23.12.2013 um 10:11 schrieb Masklinn :
>
> On 2013-12-23, at 05:12 , Corey Richardson wrote:
>
>> I find the ability to have refutable let
>
> I may have missed it, but is there a reason not to have just that? Make
> let similar to Erlang’s `=` and fail on refutation?
>
I didn’t un
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel :
> Using `match` works well enough, but if there's demand for a refutable `let`
> which is lighter-weight, what about:
>
> let Some(result) = from_utf8(some_bytes) else fail!();
>
This is a nice idea. At first I thought it wouldn’t work wit
Hi,
Am 09.12.2013 um 16:53 schrieb Damien Radtke :
> I have no idea if it would be feasible in the standard library, but wouldn't
> the ideal solution be having one function (e.g. from_utf8()) that could
> return two possible values, a bare result and an Option? Letting the compiler
> decide
Hi,
Am 17.12.2013 um 20:10 schrieb Corey Richardson :
> On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
> wrote:
>> Hi,
>>
>>
>> Am 09.12.2013 um 16:53 schrieb Damien Radtke :
>>
>>> I have no idea if it would be feasible in the standard lib
Am 09.04.2013 um 23:16 schrieb Benjamin Striegel :
> One argument in favor of John's proposal is that:
>
> let mut foo = 1,
> bar = 2;
>
maybe that should change then in favor of let mut foo = 1, mut bar = 2; ?
Cheers
Hi,
Am 02.04.2013 um 22:40 schrieb Jeaye Wilkerson :
> `let mut` makes more sense to me than `mut` simply because `let` is already a
> declarator. mut, to me, is an attribute, not a declarator. I think we should
> keep the `let mut` syntax because it's still a `let` (with regard to scope),
> b
Hi,
Am 02.04.2013 um 22:40 schrieb Jeaye Wilkerson :
> `let mut` makes more sense to me than `mut` simply because `let` is already a
> declarator. mut, to me, is an attribute, not a declarator. I think we should
> keep the `let mut` syntax because it's still a `let` (with regard to scope),
> b
ed inside a uniquely owned struct without causing it to be
copied?
That would be awesome.
Thanks,
Stefan.
> Stefan Plantikow wrote:
>>
>> Hi,
>>
>>
>> Am 21.02.2013 um 15:21 schrieb Niko Matsakis :
>>
>>> The problem with allocating memor
Hi,
Am 21.02.2013 um 15:21 schrieb Niko Matsakis :
> The problem with allocating memory in another task is that it's kind of a
> "rendezvous" operation, since you must pause both tasks so that neither
> performs a GC etc during the time of the copy. Personally I think we should
> stick with
Am 24.10.2012 um 05:49 schrieb Jesse Ruderman :
> Should functions default to pure?
>
> * With
> http://smallcultfollowing.com/babysteps/blog/2012/10/12/extending-the-definition-of-purity-in-rust/
> I think most functions will be able to be pure.
>
> * Would avoid the problem of forgetting to
Am 15.10.2012 um 17:27 schrieb Marijn Haverbeke :
> The question I guess is how often this situation comes up. Is it just
> libmath? Or is this sort of thing extremely common when doing bindings?
>
> Extremely common. I'm somewhat appalled that the blanket 'all C functions are
> unsafe' idea
Am 14.10.2012 um 22:44 schrieb Niko Matsakis :
> What Brian wrote looks about right to me. I don't think any of the deriving
> ideas we had discussed could accommodate that particular example, though
> clearly it's not hard to imagine how one might do so. Or perhaps use a macro.
>
Yes, I am
Am 12.10.2012 um 21:29 schrieb Niko Matsakis :
> +1 (one developer, one vote!) ;)
>
will there be a way to explicitly mark them as safe? Asking because if we go
down this route, all calls in libmath will become unsafe without wrapping them
in functions with unsafe blocks and that seems wrong
Hi,
Am 02.08.2012 um 22:00 schrieb Tim Chevalier :
>
> You may be able to use traits and impls to overload the name a, but if
> you don't mind giving the different functions different names, this
> way doesn't require any fancy ideas.
>
I keep wondering if we should have a way to specify a def
On 12 Jul 2012, at 1:40, Mic wrote:
Hello,
Any plans to allow rust to compile to JavaScript like dart
http://www.youtube.com/watch?v=YxogQGnMA9Y .
I'd rather see a pluggable js/lisp/lua/.. interpreter that is able to
handle arbitrary rust values once the reflection api matures to have a
RE
On 14 Jul 2012, at 13:12, David Bruant wrote:
Hi,
I'd like to bring a bit more of feedback. I've read Stateful Traits
[1]
and I was wondering how Rust intended to solve the issue mentionned in
the paper related to statelessness:
"However this simple model suffers from several limitations, in
Am Tue Jul 3 22:20:09 2012 schrieb Graydon Hoare:
On 7/3/2012 1:15 PM, Christian Siefkes wrote:
Could anyone kindly explain how to actually install a sufficiently
current
version of Rust on Linux (Debian testing, in my case)?
0.2 is the most recent release, but yes, it's sadly a few months
b
Hi,
>
> 2. You may omit the last argument of a function that expects a closure
> using a syntax like the following:
Independent from the lambda syntax (I like the ruby/smalltalkish block syntax
that is in place now), is there a reason why this is limited to closures?
It may be visually appe
Hi,
Am Donnerstag, 12. April 2012 um 15:47 schrieb Niko Matsakis:
> Not only that, but it adds an extra layer of complexity for type
> inferencing, which quite frankly is already complex enough.
>
> That said, you can do a limited form of overloading using impls:
>
> impl methods for int {
>
Hi,
Am Montag, 16. April 2012 um 20:54 schrieb Graydon Hoare:
> On 12-04-16 11:49 AM, Patrick Walton wrote:
> > On 4/16/12 11:46 AM, Graydon Hoare wrote:
> > > They're already "present" (were from the beginning) but they broke when
> > > we shifted from rustboot (hand-rolled code generator) to ru
Hi,
> 3. Type class instance coherence (what I was calling the Hashtable
> Problem)---we've still got some work to do here.
missed that mail, can you please explain what you refer to by this?
Thanks,
Stefan
___
Rust-dev mailing list
Rust-dev@moz
Hi,
> > #[abi = "rust-intrinsic"]
> > native mod intrinsics {
> > fn bswap_i16(i: i16) -> i16;
> > }
> >
> > The rust intrinsics would all just be hardcoded into the compiler to
> > translate to the appropriate llvm intrinsics.
> >
> > As an llvm intrinsic:
> >
> > #[abi = "llvm-intrinsic"]
>
Hi,
Am Sonntag, 8. April 2012 um 23:16 schrieb Brian Anderson:
>
> #[abi = "rust-intrinsic"]
> native mod intrinsics {
> fn bswap_i16(i: i16) -> i16;
> }
>
> The rust intrinsics would all just be hardcoded into the compiler to
> translate to the appropriate llvm intrinsics.
>
> As an llvm in
Hi again,
Am Sonntag, 8. April 2012 um 23:23 schrieb Sebastian Sylvan:
> On Sun, Apr 8, 2012 at 1:55 PM, Stefan Plantikow
> mailto:stefan.planti...@googlemail.com)>
> wrote:
> > > > Feedback/Suggestions?
> > >
> >
> > Is going for hopscot
try in any case ;)
> >
> > PS: Is there yet a plan on how to move towards more use of interfaces in
> > the libs, and (by extension) rustc?
>
>
> I don't think there's a plan yet. It's probably worth waiting for classes.
Ok, that makes se
/Suggestions?
PS: Is there yet a plan on how to move towards more use of interfaces in the
libs, and (by extension) rustc?
--
Stefan Plantikow
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Am Donnerstag, 1. März 2012 um 02:11 schrieb Niko Matsakis:
> While we're on the topic, what about changing the keyword `cont` to
> `next` (or `continue`, although it is long)? To be perfectly frank, I
> find the current name rather suggestive of another word that ought not
> to be uttered
hange method calls to '->', like C++, Perl, and PHP. That operator
> is free and it has precedent. And getting away from overloading the dot
> worked well when we changed module access from '.' to '::'.
>
That may just be me but I always found that ugly and slow to type (on non-us
keyboards at least)
Stefan Plantikow
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ecause they need special ABI handling when interfacing with C code and
would prefer using them with lib math where possible to be in line with f32,
f64.
--
Stefan Plantikow
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
hich may benefit
from a unified, fast, basic way to parse simple literals.
Greetings,
--
Stefan Plantikow
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Am 21.12.2011 um 17:19 schrieb Marijn Haverbeke:
> This was prompted by the 'minor annoyances thread'. A big annoyance
> for me is the recurring `_ {}` at the end of alt patterns that fall
> through. A worse form is `_ { fail "this is a bug"; }` (alt already
> fails when not matching, with a line
Am 21.12.2011 um 20:19 schrieb Marijn Haverbeke:
>> 4. Lack of break, continue, and labels. I know this is a big one but some
>> loops are difficult to write without. Anything
>> more than what is there today will be much apreciated.
>
> 'break' and 'cont' exist (though without labels, and n
Am 20.12.2011 um 19:16 schrieb Niko Matsakis:
> Hi,
>
> In preparation for the 0.1 release, Brian and I were thinking it might be
> nice to try to address small, annoying problems that come up in everyday Rust
> programming. Of course, a lot of these are already the result of compromises
> o
34 matches
Mail list logo
