[rust-dev] Porting rust to DragonFlyBSD

2014-01-07 Thread Michael Neumann
Hi there, At the moment rust only supports Linux/FreeBSD/Windows/MacOSX. I'd like to be able to compile it on DragonFlyBSD [1]. I am trying to get the FreeBSD stage0/bin/rustc to run on DragonFly, yet with no success. Is it possible to generate a static rustc binary somehow? Or what in

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2014-01-07 Thread Nick Cameron
I agree with Simon that doubling the API is inelegant. I think the solution is adding sugar to make working with Option/Result easier - (semi-)independent of the foo/foo_opt issue, I find working with Option pretty painful. I prefer the Haskell do sugar to refutable patterns in let. Similar in

Re: [rust-dev] Porting rust to DragonFlyBSD

2014-01-07 Thread Thad Guidry
I am VERY interested in the support of this platform, DragonFlyBSD. Which is a great Systems OS in and of itself. Thanks for your future efforts on it, Michael ! (BTW, in particular, I am interested in access to the HAMMER File System on DragonFlyBSD to begin my experiments) On Tue, Jan 7,

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2014-01-07 Thread Vadim
I can see how '?.' would work when foo() returns a struct, but what about non-struct types, e.g. Optioni32 ? Also, you'd still have to deal with 'None' at the end of the chain. I think in most cases I'd rather have it fail. I also don't really like refutable let-patterns proposal, because

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2014-01-07 Thread Nick Cameron
I think that you eventually have to deal with the Some or None-ness of an expression is an advantage of the ? operator, it means you can't ignore failure, but you don't have to deal with it at every step of a compound expression. Using an operator for unwrap has the same disadvantage as plain

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2014-01-07 Thread Vadim
On Tue, Jan 7, 2014 at 6:39 PM, Nick Cameron li...@ncameron.org wrote: I think that you eventually have to deal with the Some or None-ness of an expression is an advantage of the ? operator, it means you can't ignore failure, but you don't have to deal with it at every step of a compound

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2014-01-07 Thread Timothy Jones
On 8/01/2014, at 3:39 pm, Nick Cameron li...@ncameron.org wrote: I think that you eventually have to deal with the Some or None-ness of an expression is an advantage of the ? operator, it means you can't ignore failure, but you don't have to deal with it at every step of a compound

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2014-01-07 Thread Carter Schonwald
I realized something. A good near term working solution could make use of the pending procedural macros to make a nicer syntax for the and_then procedures! (or could the current syntax rules style macros work with that even?). Not sure If i'll have the time to do that experiment, but throwing

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2014-01-07 Thread Nick Cameron
Sorry, I didn't mean ignore errors as in unsafe, I meant that it allows the programmer to write code without having the error case be explicit. This is the (well, one of the) problems with null pointers in C and Java. You make a good point about errors from the API, and I guess this highlights a