On Wed, Jul 11, 2012 at 10:27 AM, Florian Weimer f...@deneb.enyo.de wrote:
This approach is fundamentally broken. If the timeout ever kicks in,
goroutines will pile up without bounds.
I just want to be clear on your comment. You mean the goroutines would pile
up, or the channel will grow
Ah, you mean after repeated invocations of the containing function in case
the timeout event keeps firing?
--
Ziad
On Wed, Jul 11, 2012 at 10:52 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Ziad Hatahet:
On Wed, Jul 11, 2012 at 10:27 AM, Florian Weimer f...@deneb.enyo.de
wrote
Not to start a religious war, but maybe using camelCase instead of
under_score would save even more space given the 78-character line limit? :)
--
Ziad
On Tue, Jul 17, 2012 at 9:03 PM, Niko Matsakis n...@alum.mit.edu wrote:
This is interesting. When I first started working on the Rust
I agree with Glenn. I personally did not have an issue while trying to pick
up Rust to figure out the implicit return with the lack of the semi-colon.
In fact, I was able to pick up this pattern just by browsing some Rust code
and not looking at the manual or tutorial pages. :)
I also think that
On Thu, Aug 23, 2012 at 8:16 PM, Jeffery Olson olson.jeff...@gmail.comwrote:
And, to be fair, another major plank of the linked post was that
Option-style library APIs aren't ubiquitous even in Scala, and
certainly not in the larger Java Class Library. This is not true for
Rust, where
+1 for sys or system.
--
Ziad
On Wed, Sep 12, 2012 at 2:55 PM, Patrick Walton pwal...@mozilla.com wrote:
On 9/12/12 2:54 PM, Brian Anderson wrote:
So I don't have any great ideas. Do you?
raw? lowlevel (ll)? machine? sys?
Patrick
__**_
So will we always have to dereference a ref variable using the asterisk
symbol? In effect this is passing a pointer (like C), correct? What about
if we want to call a method on a ref variable, will it be a.foo(), or
(*a).foo()?
Thanks
--
Ziad
On Wed, Oct 3, 2012 at 7:15 PM, Patrick Walton
On Wed, Oct 24, 2012 at 2:05 PM, Patrick Walton pwal...@mozilla.com wrote:
Oh, in that case I totally agree. I thought Nathan was asking for the
purity specified in the function signature to always match the inferred
purity of the function--in particular, for the compiler to enforce that a
Would using a dot '.' instead of a quote ' also resolve the ambiguity,
without introducing an extra sigil into the language?
{.lt}T
T{.lt}
--
Ziad
On Thu, Jan 31, 2013 at 6:33 AM, Benjamin Striegel
ben.strie...@gmail.comwrote:
+1 to this. Option 8 was always the best-case syntax, and
On Thu, Jan 31, 2013 at 7:11 AM, Dean Thompson
deansherthomp...@gmail.comwrote:
I expect it would, but at the expense of no longer being able to make as
simple a statement in the language tutorial as this:
The notation 'foo means a lifetime called foo.
To me, it seems nicer for a newbie
As others mentioned, it is to_str() instead of to_string().
You can also use the %? format string qualifier: io::println(fmt!(Tuple is
%?, (1, 2)));
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Hi all,
I was playing around with the different pointer types in Rust, and I have
the following program: https://gist.github.com/4702154
My questions/comments are listed in lines 16, 23, 27, and 29.
As a side note, I believe that there is still work being done on having
mutability depend on the
On Sun, Apr 7, 2013 at 3:01 PM, Heri Sim her...@gmail.com wrote:
Passing in a stack-local variable to a function or closure (that
requires arguments to be passed by reference), should not require the
ampersand () in the caller. Why can't the compiler figure this out?
This is one of the
Second thing: why are semicolons required at the end of lines at all? Go,
Scala etc. manage fine without.
Go has some weird edge cases due to semi-colon insertion. I don't know if
Scala managed to prevent those though.
--
Ziad
___
Rust-dev mailing
I tried the above, but I got the following errors:
$ rustc -v
rustc 0.6
host: x86_64-unknown-linux-gnu
$ cat static_type.rs
trait Newable {
fn new() - Self;
}
struct Foo(int);
impl Newable for Foo {
fn new() - Foo {
Foo(1)
}
}
fn getOneOfTheseT: Newable() - T {
let x:T =
Good article I came by via Hacker News:
http://www.yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html
I
figured people here would be interested.
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
On Wed, May 15, 2013 at 12:29 PM, Patrick Walton pwal...@mozilla.com
wrote:
You can't specify type parameters explicitly here; instead you need to use
`let test: Foo = ...`.
I just found out that the following also works:
let test = getOneOfThese::Foo();
Is one style preferred over the
On Tue, May 21, 2013 at 10:58 AM, Niko Matsakis n...@alum.mit.edu wrote:
This form is unlikely to continue working in the future. Instead, a
new syntax will be introduced. See this blog post for more details:
Say we want to implement the following function:
fn add(x: Optionint, y: Optionint) - Optionint { ... }
Some functional languages, like Haskell and Scala offer some sort of a do
notation to make unwrapping multiple Option type values easier.
add :: Maybe Int - Maybe Int - Maybe Int
add mx my =
Thanks all for the replies.
Niko, could you point out where in the code you defined the macro you
mention?
Thanks
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I replied in private at the beginning. Too :) +1
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Hi all,
Does using Option incur a runtime cost (like increased memory usage)
compared to a hypothetical case if Rust had a NULL type in the language? Or
does it get optimized away, such that it is akin to using NULL in the first
place (albeit safer of course)?
I have not looked at any
I have the following function:
fn add_equal(x: mut Complex, y: Complex) {
x.real += y.real;
x.imag += y.imag;
}
Calling the function with the same variable being passed to both arguments
(i.e. add_equal(mut c, c)), results in the compile error:
error: cannot borrow `c` as immutable
is passed on
both sides?
--
Ziad
On Sat, Jun 1, 2013 at 9:42 PM, Tim Chevalier catamorph...@gmail.comwrote:
On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet hata...@gmail.com wrote:
I have the following function:
fn add_equal(x: mut Complex, y: Complex) {
x.real += y.real;
x.imag
On Sun, Jun 2, 2013 at 6:56 AM, Daniel Micay danielmi...@gmail.com wrote:
You can currently use `const Complex` for the second parameter, but
it may or may not be removed in the future. At the very least it will
probably be renamed.
Excellent. Thanks all for your replies :)
--
Ziad
On Wed, Jun 12, 2013 at 1:08 PM, Gareth Smith
garethdanielsm...@gmail.comwrote:
My rust code breaks every time I get the latest incoming anyway - and it
is a pretty mechanical change.
I agree. There are no guarantees that current code will not break in future
versions of the language, until
On Wed, Jun 12, 2013 at 1:58 PM, Graydon Hoare gray...@mozilla.com wrote:
Eh, unclear to me. I am partial to the existing syntax (reads like
do-notation, which I think we're keeping) and avoids breaking tons of code
and adding a keyword. Also supports no-arg iteration like:
I guess I wasn't
Shouldn't we just be able to use map() and filter() routines to do the same?
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Perhaps you can get around somewhat by using macros? I asked the following
question on the mailing list a while back, so maybe something similar can
be used here:
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html
--
Ziad
___
Rust-dev
On Thu, Jun 13, 2013 at 10:43 AM, Ziad Hatahet hata...@gmail.com wrote:
Perhaps you can get around somewhat by using macros? I asked the following
question on the mailing list a while back, so maybe something similar can
be used here:
https://mail.mozilla.org/pipermail/rust-dev/2013-May
This thread made its way to the Rust subreddit, where people posted a
couple of implementations using macros. Very cool stuff!
http://www.reddit.com/r/rust/comments/1gag3t/list_comprehensions_in_rust_iterator/
http://en.wikipedia.org/wiki/List_comprehension#Rust
--
Ziad
On Sun, Jul 14, 2013 at 10:09 AM, Daniel Micay danielmi...@gmail.comwrote:
Scala, Go and D have compile-time checked, type-safe format strings for
I/O.
Unless I am missing something, Go does not check format strings at compile
time.
--
Ziad
___
On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton pwal...@mozilla.com wrote:
There's no difference except that let _ runs the destructor immediately
whereas let _foo runs the destructor at the end of the block. (This is
admittedly subtle.)
I tried the following code snippet, but nothing got
Thanks for the quick response :)
--
Ziad
On Wed, Oct 16, 2013 at 11:08 PM, Daniel Micay danielmi...@gmail.comwrote:
On Thu, Oct 17, 2013 at 2:06 AM, Ziad Hatahet hata...@gmail.com wrote:
On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton pwal...@mozilla.comwrote:
There's no difference
What about using Result types as mentioned here, but introducing some
syntactic sugar to make chaining them easier? Something like Haskell's or
Scala's do syntax:
do (
a - x // x and y are Results
b - y
) { /* do stuff with 'a' and 'b' */ }
else {
/* First Err is returned. Handle here. */
}
I came across this blog post which may be relevant:
https://coderwall.com/p/kokm7w
--
Ziad
On Fri, Oct 18, 2013 at 10:23 AM, Ziad Hatahet hata...@gmail.com wrote:
What about using Result types as mentioned here, but introducing some
syntactic sugar to make chaining them easier? Something
On Sat, Oct 19, 2013 at 1:52 PM, Patrick Walton pwal...@mozilla.com wrote:
I think it's unfortunately too late to overhaul the language like this.
This will require redesigns of all Rust code in existence.
I do like unified function/method call syntax, but I think it can be done
in a
On Sat, Oct 19, 2013 at 4:35 PM, David Piepgrass qwertie...@gmail.comwrote:
In C# it's nice that I can find all the so-called extension methods by
searching for (this .
Aren't `impl`s in Rust somewhat similar to extension methods in C#? For
instance:
trait Doubler {
fn double(self) -
On Wed, Oct 23, 2013 at 8:47 AM, Alex Crichton a...@crichton.co wrote:
With these changes, the code would look like:
use std::rt::io::File;
let mut stream = File::create(test.txt);
writeln!(mut stream, test {}, {}, {aa}, 1, 3.0, aa=2);
How would errors be handled in this
Stack overflow gets a mention in this article:
http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences:)
--
Ziad
On Tue, Oct 29, 2013 at 1:24 PM, Daniel Micay danielmi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis
Out of curiosity, why not make File::open() return a Result instead of
Option like it does now? The current implementation already seems to be
matching against the result of fs_open() and returning None if the result
is Err(). So why the extra level of indirection and raising a condition in
that
On Tue, Nov 5, 2013 at 9:17 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/5/13 2:44 AM, spir wrote:
Why not just add a declaration of the trait at the top of the struct
type def?
struct PairListVal : Iterable {
You can implement traits on types that aren't structs.
Isn't
then there could be
multiple such implementations for a given (trait, type) pair, and coherence
would be broken.
On Tue, Nov 5, 2013 at 2:28 PM, Ziad Hatahet hata...@gmail.com wrote:
On Tue, Nov 5, 2013 at 9:17 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/5/13 2:44 AM, spir wrote:
Why
.
On Tuesday, November 5, 2013, Ziad Hatahet wrote:
The following seems to work:
trait Double {
fn double(self) - Self;
}
impl Double for int {
fn double(self) - int {
*self * 2
}
}
fn main() {
let x = 2;
println!({}, x.double()); // prints 4
If structural inheritance were to be implemented, would we have the slicing
problem in Rust, as it happens in C++?
[1] http://en.wikipedia.org/wiki/Object_slicing
[2]
http://stackoverflow.com/questions/274626/what-is-the-slicing-problem-in-c/
--
Ziad
designed so that pointer types only form the
subtyping relationship, eliminating this problem.
BTW, I was thinking maybe we should just rename this feature to
structural constraints to avoid the ewww, OO reactions.
Ziad Hatahet hata...@gmail.com wrote:
If structural inheritance were
...and possibly change `~`.
To what?
--
Ziad
On Tue, Nov 12, 2013 at 1:31 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/13/13 2:37 AM, Greg wrote:
1. ~[OptionBucketK,V]
2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) -
LinearMapK,V
3. fn contains_key(self, k: K)
On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote:
No, allocation would be with `new`.
Would that have to proceed each allocation? For instance, would
let v = ~[~one, ~two, ~three];
turn into
let v = new Vector(new one, new two, new three);
?
--
Ziad
Personally I would prefer if in Rust worked similar to const T in c++
In that case, you would not be able to tell whether a function argument was
passed by value or by reference. I actually like this feature about Rust
(C# has it too with the `ref` keyword).
--
Ziad
On Tue, Nov 19, 2013 at
On Wed, Nov 20, 2013 at 10:37 AM, Brian Anderson bander...@mozilla.comwrote:
Of course, `case` doesn't mean anything in this language...
Hmm, Scala? ;)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
What about @/Gc types then? You could still potentially reuse them.
--
Ziad
On Wed, Nov 20, 2013 at 5:58 PM, Tommi rusty.ga...@icloud.com wrote:
While I'm trying to argue why the proposed solution is not a full solution
to the proposed problem, I don't even think that the proposed problem is
On Wed, Nov 20, 2013 at 5:58 PM, Tommi rusty.ga...@icloud.com wrote:
Here's why: if you make a call foo(arg) and never use arg after that,
then you don't care if arg gets moved or borrowed. And if you try to use
arg afterwards and foo did in fact move it previously, then your IDE is
going to
Would it not be possible to have new be a keyword, yet not a reserved
word (since they are not the same thing). This leaves the possibility of
using it as a method name (e.g. Struct::new()), while still using it as an
operator.
--
Ziad
On Sat, Nov 30, 2013 at 1:07 AM, David Rajchenbach-Teller
Should an issue for this be filed then?
--
Ziad
On Sat, Nov 30, 2013 at 10:20 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/30/13 10:05 AM, Kevin Cantu wrote:
While we're changing this stuff, I'd like to see lambdas allow return,
now that the need for forbidding that is gone, IIRC.
On Sat, Nov 30, 2013 at 1:54 PM, Patrick Walton pcwal...@mozilla.comwrote:
The other suggestion that's been floated that satisfies all of these
constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
should just switch to that. It's not that I'm unconcerned about `new()(1 +
On Mon, Dec 2, 2013 at 12:43 AM, Eric Reed ecr...@cs.washington.edu wrote:
In either case, I think keeping ~ as sugar for allocating on the exchange
heap would be nice (i.e. ~expr is sugar for ~expr in Unique or put
expr in Unique).
`box expr in place` reads nicely too. I don't know about
To be taken with a grain of salt, naturally:
https://www.youtube.com/watch?v=TS1lpKBMkgg
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I posted a question on the mailing list concerning this back in May:
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html
There were a couple of responses which implemented this in a macro. It
would be nice if it were at the language level though.
--
Ziad
On Fri, Dec 6, 2013 at
On Sat, Dec 7, 2013 at 2:21 PM, Gábor Lehel illiss...@gmail.com wrote:
I do wonder whether it wouldn't make sense to add sugar for Option, at
least eventually. (`int?` at the type level is really nice, too... too bad
it doesn't play so well with Rust's sigils. Introducing the potential
Thought this would be of interest to the list:
http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
.
~Brendan
On 12 Dec 2013, at 9:57 am, Zack Corr z...@z0w0.me wrote:
Yes, but Rust doesn't have HKT. I was suggesting it on this basis. I'd
prefer `do` as well.
On Wed, Dec 11, 2013 at 5:25 PM, Ziad Hatahet hata...@gmail.com
wrote:
On Tue, Dec 10, 2013 at 9:04 PM, Zack Corr z...@z0w0.me wrote
Can you have the definition be: fn get_fieldsT(self) - ~[@FieldT];?
--
Ziad
On Sun, Dec 15, 2013 at 3:13 AM, Andres Osinski andres.osin...@gmail.comwrote:
I'll have to consider it. To be honest this is my first endeavor in
attempting to capture classic OO business object-y rules using
I favor this approach too. As an example, Scala does something similar: a
call to Map() constructs an immutable map object (it is in the default
namespace), whereas if you want a mutable Map object, you have to import it
from scala.collection.mutable.Map.
--
Ziad
On Fri, Dec 20, 2013 at 10:50
But we already have Option::unwrap_or() and Option::unwrap_or_else() that
behave similar to the 'else' syntax suggested above.
--
Ziad
On Sun, Dec 22, 2013 at 10:37 AM, Léo Testard leo.test...@gmail.com wrote:
Hello,
Le 22 déc. 2013 à 18:59, Stefan Plantikow stefan.planti...@gmail.com a
Zack Corr z...@z0w0.me z...@z0w0.me
Ziad Hatahet hata...@gmail.com hata...@gmail.com
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Isn't this proposal a subset of having `do` syntax like Haskell does? I
thought that was being blocked on HKTs.
--
Ziad
On Mon, Feb 10, 2014 at 4:40 AM, Armin Ronacher armin.ronac...@active-4.com
wrote:
Hi,
On 10/02/2014 11:50, Huon Wilson wrote:
It's actually Haskell's fmap, which we
Kind of off-topic, but there is a heated discussion on the D language
forums about why having non-virtual base class methods by default is a bad
idea:
http://forum.dlang.org/thread/lfqoan$5qq$1...@digitalmars.com
Also comes up here:
Hey Phil,
That's precisely why I opened the following PR:
https://github.com/mozilla/rust/pull/12960
But as Daniel and Alex pointed out, it is pretty redundant. Alex also
pointed out that the LLVM optimization pass will optimize away the return
value.
Scala also allows you to use `for` to deal
Hi all,
Are there any plans to implement structural typing in Rust? Something like
this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
, 2014 at 11:37 AM, Liigo Zhuang com.li...@gmail.comwrote:
IMO, this is bad.
2014年3月23日 下午6:34于 Ziad Hatahet hata...@gmail.com写道：
Hi all,
Are there any plans to implement structural typing in Rust? Something
like this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala
Thanks for the feedback everyone. It makes sense how things currently are
for Rust.
Keep up the great work!
--
Ziad
On Sun, Mar 23, 2014 at 4:54 PM, Liigo Zhuang com.li...@gmail.com wrote:
+1
2014年3月24日 上午5:46于 Patrick Walton pcwal...@mozilla.com写道：
On 3/23/14 2:19 PM, Ziad Hatahet wrote
Would a macro address this situation?
--
Ziad
On Mon, Mar 24, 2014 at 5:12 PM, comex com...@gmail.com wrote:
On Mon, Mar 24, 2014 at 7:32 PM, Richo Healey ri...@psych0tik.net wrote:
let vec: [u8, .. FooBar::size()];
Potentially with parens ommittted, to convey that there's no runtime
On Thu, Apr 3, 2014 at 11:09 AM, Daniel Micay danielmi...@gmail.com wrote:
Go doesn't have an equivalent to what `~[T]` will be.
Which was my point. From what I understand, Go's slices are analogous to
Rust's VecT in that they are growable. So I was suggesting perusing
existing Go code bases
On Tue, Apr 15, 2014 at 10:20 AM, Steve Klabnik st...@steveklabnik.comwrote:
I can finally retire that bookmark to
https://mail.mozilla.org/pipermail/rust-dev/2013-April/003867.html !
How will that change though? Won't we still have to call `.equiv()`?
Furthermore, wasn't the plan to use
So the new Vec and Str/StrBuf types are all reference types, correct?
What happens if we pass around a borrowed or owned pointer to one of these
types? Won't there be an extra level of indirection to get to the
underlying data pointer?
--
Ziad
On Tue, Apr 15, 2014 at 11:10 AM, Corey Richardson
Would it be worth introducing an own!() macro for this purpose? I came
across this suggestion on the reddit thread:
http://www.reddit.com/r/rust/comments/2340zb/rustdev_removing_foo/
--
Ziad
On Tue, Apr 15, 2014 at 10:12 AM, Patrick Walton pcwal...@mozilla.comwrote:
Hi everyone,
I'd like to
Confirm repro on an older rustc version. Ubuntu 13.10 running rustc
0.11-pre (ecc774f 2014-04-11 13:46:45 -0700).
--
Ziad
On Fri, Apr 18, 2014 at 4:38 AM, Phil Dawes rustp...@phildawes.net wrote:
Hello everyone,
I was trying to create an iterator that used a function pointer to
alternate
77 matches
Mail list logo
