Re: [rust-dev] possible code dump bug (state machine iterator)
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 between different states, and ended up core dumping. I've pasted
a version that generates the issue on my box (Ubuntu 12.04 LTS,
rust-nightly pulled just now). Can anybody reproduce this on their
machines? If so I'll file a bug.
Cheers,
Phil
struct StateMachineIter'a {
statefn: 'a fn(mut StateMachineIter'a) - Option'static str
}
impl'a Iterator'static str for StateMachineIter'a {
fn next(mut self) - Option'static str {
return (*self.statefn)(self);
}
}
fn state1(self_: mut StateMachineIter) - Option'static str {
self_.statefn = state2;
return Some(state1);
}
fn state2(self_: mut StateMachineIter) - Option('static str) {
self_.statefn = state3;
return Some(state2);
}
fn state3(self_: mut StateMachineIter) - Option('static str) {
self_.statefn = finished;
return Some(state3);
}
fn finished(_: mut StateMachineIter) - Option('static str) {
return None;
}
fn state_iter() - StateMachineIter {
StateMachineIter { statefn: state1 }
}
fn main() {
let mut it = state_iter();
println!({},it.next());
println!({},it.next());
println!({},it.next());
println!({},it.next());
println!({},it.next());
}
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing ~foo
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 `box(string)` to create owned pointers? -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing ~foo
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 co...@octayn.net wrote: `box foo` would create a SomeBox'static str, as outlined in the meeting notes: box foo - Heap'static Str foo.to_owned() - HeapStr (or ~Str) Heap::from(foo) - HeapStr (or ~Str) Rc::from(foo) - RcStr On Tue, Apr 15, 2014 at 2:06 PM, SiegeLord slab...@aim.com wrote: On 04/15/2014 01:12 PM, Patrick Walton wrote: The new replacement for `~foo` will be `foo.to_owned()`. You can also use the `fmt!()` macro or the `.to_str()` function. Post-DST, you will likely also be able to write `Heap::from(foo)`. Why not `box foo`? Is that scheduled to break? -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing ~foo
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 remove the `~foo` literal syntax for owned strings in both expressions and patterns. After dynamically sized types, this syntax is the last remnant of the strange parser behavior by which the parser does something different for `~foo` and `~(foo)` (i.e. by which it looks at the next token when it sees a sigil and does something different than it would otherwise). The new replacement for `~foo` will be `foo.to_owned()`. You can also use the `fmt!()` macro or the `.to_str()` function. Post-DST, you will likely also be able to write `Heap::from(foo)`. This has no effect on constants since `~foo` is not allowed there anyway. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Reminder: ~[T] is not going away
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 to see how often slices returned from standard library routines are appended to; which seems to be one motivator for ~[T]. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vector length specified by enum
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 computation? Not sure if it matters, but another thing one might want to use in a constant expression is sizeof, which wouldn't necessarily be amenable to a similar approach. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Structural Typing
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
Re: [rust-dev] Structural Typing
You wouldn't probably use this for each and every method, but what it gives you is Go-style duck typing. Sure you can define a trait, but what if the struct you to pass to your function does not implement it? I guess you would have to implement a wrapper around it manually then. -- Ziad On Sun, Mar 23, 2014 at 4:37 AM, Matthieu Monrocq matthieu.monr...@gmail.com wrote: I would note that Rust macros are actually working with structural typing: the expanded macro cannot be compiled unless the expressions/statements it results in can be compiled. Regarding Scala here, it seems a weird idea to ask that each and every method should copy+paste the interface. We all know the woes of duplication. Instead, you can define a Trait (even if for a single function) and it'll just work; and when you add a second function you will be able to re-use the same trait. On Sun, Mar 23, 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Structural Typing
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: You wouldn't probably use this for each and every method, but what it gives you is Go-style duck typing. Sure you can define a trait, but what if the struct you to pass to your function does not implement it? I guess you would have to implement a wrapper around it manually then. I don't think Go-style duck typing turns out to be that useful in practice to solve this problem, because the chances that two independently-developed libraries that wanted to expose some functionality on their object, say, `Munge()`, would give the function exactly the same name and give exactly the same types to its arguments, (in the same order!) is astronomically small. In reality the primary benefit of Go-style duck typing is the ability to avoid having to type the name of the trait you're implementing at the implementation site. What you give up for this is the ability to provide extension methods: i.e. implementation of a trait for a type *outside* of the package that defined the type. This is a huge downside, and I don't think it's worth it on the whole; this is why Rust's traits are designed the way they are. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Idomatic option handling
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 with options. This is especially
useful when you have multiple optional values, and you want them to all be
`Some`s to proceed. E.g.
val x = Some(3)
val y = Some(4)
val sum = for {
a - x
b - y
} yield (a + b) // sum is now Some(7)
The word is that hopefully Rust will gain this capability fully when HKTs
are implemented (possibly using the `do` keyword). Right now there are a
couple of macro implementations that mimic this feature, and they were
posted on the mailing list.
Cheers
--
Ziad
On Tue, Mar 18, 2014 at 1:56 PM, Phil Dawes rustp...@phildawes.net wrote:
Hello!
I had my first github patch yesterday - Hatahet kindly cleaned up some
code for me. I was using match to destructure the Optionuint output from
str.find_str(), but then doing nothing with the None case. He wrote:
'The match expression for options is good for when you want to deal with
both cases of the Option type -- namely Some and None. If you only deal
with Some, then you can cut down on some redundancy by using Option.map()
or Option.iter().'
https://github.com/phildawes/racer/pull/1
so all the instances of
match line.find_str(..) {
Some(n) = {
...
}
None = {}
}
became:
for n in line.find_str(..).move_iter() {
...
}
Which is much more consise and so I applied the patch.
However now reading it again I find using 'for' in this way a bit
confusing because it says to me that there are potentually multiple results
to the find_str() method (implying that it finds multiple matches of the
string when really it does not).
Using map looks is less confusing to my eyes, but it feels hacky because
I'm discarding the result and I guess is still imply iteration over
multiple results:
line.find_str(..).map(|n|{
...
});
Is there a clearer way?
Thanks,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
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: http://forum.dlang.org/thread/zkmunpiikmrezbzme...@forum.dlang.org ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Chaining Results and Options
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 have in the form of .map for both Option[1] and Result[2], e.g. the proposed expr-method() is the same as expr.map(|x| x.method()) (which is still quite verbose). The return value of .method() is actually a Result/Option so it would be more similar to .and_then: foo-bar() // would be the same as foo.and_then(|x| x.bar()); Regards, Armin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.9 released
...@jschaf.com j...@jschaf.com John Louis Walker inj...@gmail.com inj...@gmail.com Jordi Boggiano j.boggi...@seld.be j.boggi...@seld.be Joshua Yanovski pythones...@gmail.com pythones...@gmail.com Julia Evans ju...@jvns.ca ju...@jvns.ca Jyun-Yan You jy...@cs.nctu.edu.tw jy...@cs.nctu.edu.tw Keegan McAllister kmcallis...@mozilla.com kmcallis...@mozilla.com Kevin Ballard ke...@sb.org ke...@sb.org Kiet Tran ktt...@gmail.com ktt...@gmail.com klutzy klutzytheklu...@gmail.com klutzytheklu...@gmail.com kud1ing git...@kudling.de git...@kudling.de Leah Hanson astriea...@gmail.com astriea...@gmail.com LEE Wondong wdle...@gmail.com wdle...@gmail.com Léo Testard leo.test...@gmail.com leo.test...@gmail.com Lindsey Kuper lind...@composition.al lind...@composition.al Luca Bruno lu...@debian.org lu...@debian.org Luis de Bethencourt l...@debethencourt.com l...@debethencourt.com Luqman Aden la...@csclub.uwaterloo.ca la...@csclub.uwaterloo.ca lyuts diox...@gmail.com diox...@gmail.com Mark Rowe mr...@bdash.net.nz mr...@bdash.net.nz Marvin Löbel loebel.mar...@gmail.com loebel.mar...@gmail.com Matt Carberry carberry.m...@gmail.com carberry.m...@gmail.com Matthew Auld matthew.a...@intel.com matthew.a...@intel.com Matthew Iselin matt...@theiselins.net matt...@theiselins.net Micah Chalmer mi...@micahchalmer.net mi...@micahchalmer.net Michael 'devbug' Williams m.t.willi...@live.com m.t.willi...@live.com Michael Letterle michael.lette...@gmail.commichael.lette...@gmail.com Michael Woerister michaelwoerister@gmail niftynif nif.w...@gmail.com nif.w...@gmail.com Niko Matsakis n...@alum.mit.edu n...@alum.mit.edu Noufal Ibrahim nou...@nibrahim.net.in nou...@nibrahim.net.in Olivier Saut os...@airpost.net os...@airpost.net osa1 omeraga...@gmail.com omeraga...@gmail.com Palmer Cox p...@lmercox.com p...@lmercox.com Patrick Walton pcwal...@mimiga.net pcwal...@mimiga.net Peter Zotov whitequ...@whitequark.org whitequ...@whitequark.org Philipp Brüschweiler ble...@gmail.com ble...@gmail.com Raphael Speyer rspe...@gmail.com rspe...@gmail.com reedlepee reedlepee...@gmail.com reedlepee...@gmail.com Richard Diamond wich...@vitalitystudios.comwich...@vitalitystudios.com Robert Irelan rire...@gmail.com rire...@gmail.com Scott Lawrence byt...@gmail.com byt...@gmail.com Sébastien Chauvel eichi...@mailoo.org eichi...@mailoo.org Sébastien Crozet develo...@crozet.re develo...@crozet.re Sébastien Paolacci sebastien.paola...@gmail.comsebastien.paola...@gmail.com Seo Sanghyeon sanx...@gmail.com sanx...@gmail.com sh8281.kim sh8281@samsung.com sh8281@samsung.com SiegeLord slab...@aim.com slab...@aim.com sp3d sp3d@github S Pradeep Kumar gohan...@gmail.com gohan...@gmail.com Steve Klabnik st...@steveklabnik.com st...@steveklabnik.com Steven Fackler sfack...@gmail.com sfack...@gmail.com Strahinja Val Markovic v...@markovic.io v...@markovic.io Tim Chevalier cheval...@alum.wellesley.educheval...@alum.wellesley.edu Tomas Sedovic to...@sedovic.cz to...@sedovic.cz Vadim Chugunov vadi...@gmail.com vadi...@gmail.com Vijay Korapaty r...@korapaty.com r...@korapaty.com Volker Mische volker.mis...@gmail.com volker.mis...@gmail.com Young-il Choi duddlf.c...@samsung.com duddlf.c...@samsung.com Zach Kamsler smoo.mas...@gmail.com smoo.mas...@gmail.com 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 Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
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
écrit :
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel glaebho...@gmail.com:
This is a nice idea. At first I thought it wouldn’t work with `if` but
in expressions `if` requires `else` so the grammar wouldn’t be ambiguous:
No, it doesn't. As long as the if's true block returns unit.
let foo = if ... { }; is perfectly legal, even it doesn't make much sense
in practice.
Leo
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Iterator naming convention
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 PM, Alex Crichton acrich...@mozilla.comwrote: In the past we have explicitly attempted to drop as many suffixes as possible (see #8090). This is a little bit of a tricky topic, and to me it depends on how you name the iterator. To me, iter::Map and container::Map are clearly different if they are named that way. If they are imported and then named via Map, then I can see how there would be some confusion. I have a preference to naming things through a module instead of importing giant numbers of capital-letter things at the top of a file. We already have an open issue about reorganizing libstd (#9208) with a major goal of reducing stuttering all over the place (which adding Iterator suffixes would add in a few places). Mostly just food for thought. On Fri, Dec 20, 2013 at 8:51 PM, Palmer Cox palmer...@gmail.com wrote: I noticed recently that there seem to be 3 distinct Iterator naming conventions currently in use: 1. Use the Iterator suffix. Examples of this are SplitIterator and DoubleEndedIterator. 2. Use the Iter suffix. Examples of this are ChunkIter and ComponentIter. 3. Use no particular suffix. Examples of this are Invert and Union. Iterators are somewhat special objects, so, it makes sense to me that they have a suffix in common to denote their common behavior. It seems non-ideal, however, that there appear to be 3 separate conventions in use since that is just confusing. Personally, I think I prefer #1 because its far and away the most common and and because I think #2 and #3 have issues: #2 (Iter suffix): If we used this suffix, would we rename DoubleEndedIterator to DoubleEndedIter? That looks awkward since we abbreviated Iterator without abbreviating anything else. However, DblEndedIter is a monstrosity. So, this convention seems non-ideal to me. #3 (no suffix): I think its pretty confusing while reading through code that there are both iter::Map and container::Map since they are completely unrelated. I'm also not a big fan of Union since I think as a union as a collection of information that I can iterate multiple times. However, since Union is itself an Iterator, I can only iterate it once. This means I would have to be careful passing a Union around to make sure I don't pass around an already iterated Union object. So, I opened up https://github.com/mozilla/rust/pull/11001 to standardize on #1 - all Iterators have an Iterator suffix. Thoughts? -Palmer Cox ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Trait container return types
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 Rust-style
traits, and evidently I have some gaps in my knowledge and how to design
around those constraints.
On Sun, Dec 15, 2013 at 7:52 AM, Eric Reed ecr...@cs.washington.eduwrote:
I'm on a phone so I haven't tested this, but I'd suggest removing the T
parameter of Field and replacing uses of T with Self. In case you don't
already know, Self is a implicit type parameter representing the type of
self, i.e. the type you impl the trait for. Would that work for your use
case?
On Dec 15, 2013 2:40 AM, Andres Osinski andres.osin...@gmail.com
wrote:
I have not gotten around to examining the ownership issues of @-boxes -
I've used them because they're mentioned as the only way to do runtime
polymorphism - but I will definitely be looking at the Any type.
The essential point is that, for a set of FieldT containers, I want to
invoke a method whose signature does not have generic type parameters,
name the is_valid() method which would return a bool.
The thing is, the specialization for Field is something that I want to
leave open to the user, so an Enum solution or any solution which places a
constraint on T is not good for my use case. I'm open to doing whatever
unsafe manipulations would be necessary, but unfortunately there's not that
much code that's been written to go around to get an example.
On Sun, Dec 15, 2013 at 7:24 AM, Chris Morgan m...@chrismorgan.infowrote:
The problem there is that `@Field` is not a type, because you haven't
specified the value for the generic constraint T. That is, the
pertinent trait object would be something like `@Fieldint`. It's not
possible to have a field without the type being specified; that is,
`get_fields()` can only be designed to return fields of one type
(think of it this way—what will the type checker think of the value of
`model.get_fields()[0].get()`? It's got to be exactly one type, but
it's not possible to infer it).
You'd need to deal with something like std::any::Any to achieve what
it looks likely that you're trying to do. Because I wouldn't encourage
designing something in that way as a starting point, I won't just now
give you code covering how you would implement such a thing; see if
it's possible for you to design it in such a way that this constraint
doesn't cause you trouble. Using enums instead of traits is one way
that can often—though certainly not always—get around this problem.
One final note—avoid using @-boxes if possible; is it possible for you
to give owned pointers or references?
On Sun, Dec 15, 2013 at 7:24 PM, Andres Osinski
andres.osin...@gmail.com wrote:
Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a
library to manage some common business object behavior.
trait FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~str, ~[FieldError] {
}
The code fails with the following compiler error:
models.rs:80:35: 80:40 error: wrong number of type arguments:
expected 1 but
found 0
models.rs:80 fn get_fields(self) - ~[@Field];
The reason for the get_fields() method is to return a list of
heterogenous
trait-upcasted objects, and for each of them I'd be invoking the
is_valid()
method.
I would understand that the compiler may not understand the notion of
trait
return types (which would make sense) but I'd be interested to know
whether
this is a bug or a design limitation, and in the second case, whether
there's a sensible alternative.
Thanks
--
Andrés Osinski
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] List of potential C# 6.0 features
If `do` is going away from being used as syntactic sugar to invoke
functions with closure arguments, would it be a possibility to use it here?
--
Ziad
On Wed, Dec 11, 2013 at 6:30 PM, Zack Corr z...@z0w0.me wrote:
It could certainly be implemented now, if it was restrictive to builtin
monad types - like `Option`. The real question would be what sort of syntax
fits in with Rust. Would there be a new bind operator, or have `bind`
instead of `let` in `do` blocks or just reuse let and have any option types
be automatically deconstructed in the binding (yuck).
For example using the first,
fn str_larger_than_five(str: ~str) {
do {
val - from_str(1);
return val 5;
}
}
or perhaps a bind keyword would nicer (my preference, but requires an
extra keyword):
bind val = from_str(1);
return val 5;
Of course the current usage of `do` would need to be removed in favour of
another keyword.
On Thu, Dec 12, 2013 at 10:55 AM, Brendan Zabarauskas bjz...@yahoo.com.au
wrote:
Could `do` be implemented using sugar for now? Like, it expects such and
such methods in order for it to work. We could put it behind a feature flag
until we have HKT.
~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:
I think the Monadic null operator (a.k.a. safe property access
operator) would be pretty useful syntax sugar for mapping over option
types, and certainly help with the whole option vs fail for error
checking because it essentially allows monad-like functionality without
actually having (first-class) monads.
I still think that having something like Haskell's `do`, or Scala's
`for` is a better way to go about this. Especially that it generalizes over
more than just `OptionT`.
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] List of potential C# 6.0 features
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
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
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 confusion between `~?T` and `?~T` is probably a step too far.) Wouldn't it be better to add something similar to Haskell's `do` instead of another sigil? -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
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 5:14 PM, Huon Wilson dbau...@gmail.com wrote:
On 07/12/13 12:08, Jordi Boggiano wrote:
On Sat, Dec 7, 2013 at 2:01 AM, spir denis.s...@gmail.com wrote:
On 12/07/2013 01:12 AM, Gaetan wrote:
I am in favor of two version of the api: from_str which has already done
the unwrap, and a from_str_safe for instance that returns a Result or
option.
This provides the important semantic information (that I've evoked at the
end end of a long earlier reply in this thread) of whether func failure
is
expected and belongs to the logic of the present app and we must deal
with
it, or not.
But I'm still shared on this topic for finding it also annoying, like
Simon,
to have to duplicate whole catogories of such funcs (of which we cannot
know
in advance whther they'll fail or not), if only the interface as
apparently
proposed by Gaëtan.
Syntax sugar like this would be nice:
let str = std::str::from_utf8(Parse this optimistically, and fail
otherwise);
// str is a string or the task fails
vs.
let opt_str = std::str::from_utf?(Parse this if valid); // note the
question mark
if opt_str.is_some() { }
Problem is, this sounds scary to implement at the compiler level, if
it's possible at all :) I am just throwing it out there for others to
judge.
Cheers
I personally think a better solution is something like Haskell's do
notation[1], where you can chain several computations that return
Option.. such that if any intermediate one returns None, the later ones
are not evaluated and the whole expression returns None, which saves having
to call .get()/.unwrap()/.expect() a lot.
This can work for types like Result too (in fact, the Haskell
implementation of `do` is sugar around some monad functions, so any monad
can be used there; we currently don't have the power to express the monad
typeclass/trait in Rust so the fully general form probably isn't possible
as a syntax extension yet, although a limited version is).
Huon
[1]: http://en.wikibooks.org/wiki/Haskell/do_Notation
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Interesting talk about (scala) language/compiler complexity
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
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 any ambiguity in the syntax though. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 dtel...@mozilla.com wrote: On 11/30/13 10:01 AM, Kevin Ballard wrote: `new` isn't self-documenting. It's merely consistent with C++, but consistency with C++ cannot be considered self-documentation because there are a great many programmers out there who have never touched C++ (or any language with a `new` operator). To someone who hasn't encountered `new` before, an equally-valid interpretation of `new Foo` would be to construct a `Foo` value by invoking a standard initializer, returning it by-value. I believe that Patrick's argument is that the primary target of Rust is people who are already familiar with C++. To them, `new` will be self-documenting. Programmers who are not familiar with `new` (who are getting rare these days) will still need to learn a new construct, just as they would with sigils. I do not have a very strong opinion, but I believe that `new` is indeed a good way to astonish the least amount of newcomers. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] do
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. That's more likely to continually trip me up than unusual allocation mechanisms. No objections here. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 + 2)` being weird: it's that I'm more concerned about what's not going to make C++ programmers run away. Patrick +1 for `alloc`. It is straightforward and to the point. Another important (IMO) advantage is that we would be able to use `new()` as a method name, instead of `init()`, which is very confusing, and conveys the wrong meaning. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] list of all reserved keywords of the language
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
Re: [rust-dev] Removing some autoref magic
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 a problem. 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 tell you about it by drawing a red squiggly line under that incorrect use of arg. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing some autoref magic
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 tell you about it by drawing a red squiggly line under that incorrect use of arg. This is from the point of view of the person writing the code. What about someone reading the code? He/she would either have to go through the remainder of the function/scope to make sure that `arg` was not being used (if it were, then it was a borrow, otherwise, it could have been either a borrow or a move); or they would have to look at the signature of `foo()`; as opposed to just being able to tell right there at the call site. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing some autoref magic
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 4:54 PM, Vadim vadi...@gmail.com wrote: So why did Rust adopt auto-moving instead of explicit moving? If the second example had to be written as foo(move a) there would be no confusion. The and the third example should arguably be sort(mut a.as_mut_slice()). Personally I would prefer if in Rust worked similar to const T in c++ (i.e. for most intents and purposes you can treat a reference as a value), otherwise half of the arguments on each function call will have to be adorned with ampersands. Can we have it such that foo(a) would be guaranteed to not mutate or move a and require mut or move prefix otherwise? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
...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) My approach would be to try and get rid of templates through better type inference in the compiler. We need the ability to define custom generic containers, which are essential for high-performance code. The Go/JS-like approach of building a few blessed containers into the language doesn't work when you need fine-grained control over data representations, which we need to build a competitive browser engine among other considerations. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). We use the brace literal syntax for objects already, so we need something different. I do think that having a map literal syntax would be nice, but that can probably be done via the macro system for now. I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. The current thinking is to remove `@` and possibly change `~`. `` will likely not change because of familiarity from C++. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. We do support reference counting. The fact that we offer GC is a choice that gives control to the programmer. A broader point, though, is that syntax seems to me to be a very unimportant concern when making decisions that impact performance and control. Users of high-performance software, who vastly outnumber the developers and who never see the source code, aren't going to accept tradeoffs made to source-level aesthetics that simultaneously have the effect of making their software slow. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Can you elaborate? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Implementation Inheritance / mixins
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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Implementation Inheritance / mixins
Very cool. I agree that naming will have an effect on psychology. A similar case is the type of reactions the word template may evoke, when it reminds people of the way C++ does them. -- Ziad On Sat, Nov 16, 2013 at 12:15 PM, Patrick Walton pwal...@mozilla.comwrote: Nope. It's carefully 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 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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] the inter-play of struct type impl, traits, type params
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 another effect of this is the ability to monkey-patch structs to
implement extra methods or traits? E.g. you can later in implement a
to_str() method for a type, or implement certain traits, like Clone or Drop.
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] the inter-play of struct type impl, traits, type params
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
}
--
Ziad
On Tue, Nov 5, 2013 at 1:29 PM, Steven Blenkinsop steven...@gmail.comwrote:
As long as you are the person who owns the type, yeah, but I suspect
that's not what you mean. Coherence requires that you only implement traits
for types if you own either the trait or the type (or both). You can't
implement a 3rd party trait for a 3rd party type, since 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 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 another effect of this is the ability to monkey-patch structs to
implement extra methods or traits? E.g. you can later in implement a
to_str() method for a type, or implement certain traits, like Clone or Drop.
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] the inter-play of struct type impl, traits, type params
Gotcha. But it is still pretty flexible in that you are not bound to the
impls that were originally defined on the type (e.g. like C++/Java where
the list of interfaces implemented by a class are fixed). This relieves one
form writing wrapper classes in order for certain structs to adhere to
particular interfaces.
--
Ziad
On Tue, Nov 5, 2013 at 8:25 PM, Steven Blenkinsop steven...@gmail.comwrote:
Here you own the trait Double. Doesn't work if you were trying to
implement a trait you hadn't just defined. The specific examples you
mentioned were Clone and Drop, so that wouldn't work.
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
}
--
Ziad
On Tue, Nov 5, 2013 at 1:29 PM, Steven Blenkinsop steven...@gmail.comwrote:
As long as you are the person who owns the type, yeah, but I suspect
that's not what you mean. Coherence requires that you only implement traits
for types if you own either the trait or the type (or both). You can't
implement a 3rd party trait for a 3rd party type, since 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 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 another effect of this is the ability to monkey-patch structs
to implement extra methods or traits? E.g. you can later in implement a
to_str() method for a type, or implement certain traits, like Clone or
Drop.
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Checking error at opening file
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 case?
--
Ziad
On Sat, Nov 2, 2013 at 10:42 PM, Alex Crichton a...@crichton.co wrote:
This api is a little in flux (hopefully #10179 will land soon), but
I'm not quite sure what you mean about keeping the file descriptor
open. If there was an error opening the file, then a file descriptor
was never allocated and there's nothing to keep open. Regardless, once
my pull request lands, your example would look something like:
use std::rt::io;
use std::rt::io::File;
match io::result(|| File::open(Path::new(/some/path)) {
Ok(file) = { /* file was successfully opened, it existed */ }
Err(e) = { /* file couldn't be opened, error contained in e */ }
}
On Sat, Nov 2, 2013 at 5:34 PM, John Mija jon...@proinbox.com wrote:
How to check an error at opening a file but without closing its file
descriptor?
use std::path;
use std::rt::io;
use std::rt::io::file;
let filename = /some/path;
let f = file::open(path::Path::new(filename), io::Open, io::Read);
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] More on stack safety
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 n...@alum.mit.edu wrote: If I understand correctly, what you are proposing is to offer fixed size stacks and to use a guard page to check for stack overflow (vs a stack preamble)? My two thoughts are: 1. I do think segmented stacks offer several tangible benefits: - Recursion limited only by available memory / address space - Avoid chewing up address space on 32 bit builds However, I can accept that on balance they are not worth the price, given that point #2 is probably not that important for 64-bit systems. It is sad to lose limitless recursion but typically one can rewrite routines that recurse arbitrarily deep to use a stack on the heap, though sometimes the code is very unnatural, and using a stack on the heap will not play as well with lifetimes, since the compiler doesn't know that you are obeying a stack discipline. 2. I think that our official semantics for stack overflow should be task failure, not abort. There are some technical challenges to be overcome with regard to the best way to signal/detect stack overflow, and I'm fine with this being a todo item (possibly for a long time). But abort is wrong. One non-technical difficulty to failing on overflow is how to handle user-defined destructors when there is no stack to run them on -- but I think this is adequately addressed by keeping a red zone (so that simple dtors work) and implementing Graydon's plan for handling recursive failure otherwise. We also have to modify drop glue to not be recursive (see point #1 about the convenience of limitless recursion -- though of course drop glue must be ready for OOM as well). If we want to unwind on task failure, we'll need to disable the `prune-eh` pass that bubbles up `nounwind` since every function will be able to unwind. I think it will cause a very significant increase in code size. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] writing file
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 case? Raising conditions?
Thanks
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unified function/method call syntax and further simplification
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 backwards compatible way.
What do you have in mind at the moment? Implementing UFCS while still
keeping the `impl` syntax around for structs? What about for primitive
types, e.g. would `fn double(a: int) - { 2*a }` be callable as
`2.double()`, without breaking backward compatibility?
Thanks
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unified function/method call syntax and further simplification
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) - Self;
}
impl Doubler for int {
fn double(self) - int { *self * 2 }
}
Then you can call 5.double().
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
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. */
}
--
Ziad
On Thu, Oct 17, 2013 at 9:40 PM, Igor Bukanov i...@mir2.org wrote:
So the Go style is to call a function, check if the was an error,
update the error object (or create a new wrapping the old one) with
extra information relevant to the current call stack frame and
propagate the updated error object to the caller. If done
consistently, this could indeed provide very-user friendly error
messages. But it does clutter the code with if checks and does not
allow to recover so multiple errors could not be reported.
In the above example the developer, before calling a parser library,
may want to say that IO errors should be recovered from, so they could
be reported together with other problems like syntax violations. I do
not see how the Go style could be adopted to that. In its design the
caller cannot influence the error propagation paths in the callee and
its stack subframes.
On 18 October 2013 05:29, Steven Blenkinsop steven...@gmail.com wrote:
On Thursday, October 17, 2013, Igor Bukanov wrote:
Go - I have not used the language, but my general impression is that
no error will be generated. Instead the file will be read as an empty
string.
Go encodes the error as a value which can be either treated as a string
or
programmatically inspected to determine the correct response and returns
it
along with an invalid file handle. If the code doesn't actually
specifically
handle permission problems, it will usually create a new error value
embedding the original error along with some context about what it was
doing
when it got the error. This new error can then be used as a failure
value or
passed up the stack, or it may be logged (potentially in combination with
one of the other two options). This means that, even if the developer
didn't
anticipate permissions issues, the error will likely contain all the
relevant information, such as what line of the configuration file was
being
processed as well as what file failed to open and why.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
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 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. */
}
--
Ziad
On Thu, Oct 17, 2013 at 9:40 PM, Igor Bukanov i...@mir2.org wrote:
So the Go style is to call a function, check if the was an error,
update the error object (or create a new wrapping the old one) with
extra information relevant to the current call stack frame and
propagate the updated error object to the caller. If done
consistently, this could indeed provide very-user friendly error
messages. But it does clutter the code with if checks and does not
allow to recover so multiple errors could not be reported.
In the above example the developer, before calling a parser library,
may want to say that IO errors should be recovered from, so they could
be reported together with other problems like syntax violations. I do
not see how the Go style could be adopted to that. In its design the
caller cannot influence the error propagation paths in the callee and
its stack subframes.
On 18 October 2013 05:29, Steven Blenkinsop steven...@gmail.com wrote:
On Thursday, October 17, 2013, Igor Bukanov wrote:
Go - I have not used the language, but my general impression is that
no error will be generated. Instead the file will be read as an empty
string.
Go encodes the error as a value which can be either treated as a string
or
programmatically inspected to determine the correct response and
returns it
along with an invalid file handle. If the code doesn't actually
specifically
handle permission problems, it will usually create a new error value
embedding the original error along with some context about what it was
doing
when it got the error. This new error can then be used as a failure
value or
passed up the stack, or it may be logged (potentially in combination
with
one of the other two options). This means that, even if the developer
didn't
anticipate permissions issues, the error will likely contain all the
relevant information, such as what line of the configuration file was
being
processed as well as what file failed to open and why.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
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 printed out. What am I
missing?
-- cut --
struct S;
impl Drop for S {
fn drop(mut self) {
println(drop);
}
}
fn main() {
let _ = S;
}
--end cut --
Replacing `let _` with `let _s` printed drop as expected.
Thanks
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
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 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 printed out. What am
I missing?
-- cut --
struct S;
impl Drop for S {
fn drop(mut self) {
println(drop);
}
}
fn main() {
let _ = S;
}
--end cut --
Replacing `let _` with `let _s` printed drop as expected.
Thanks
--
Ziad
https://github.com/mozilla/rust/issues/6892
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] bikeshedding println() and friends
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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The 'for' syntax for iterators
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
Re: [rust-dev] The 'for' syntax for iterators
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 mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The 'for' syntax for iterators
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/004176.html -- Ziad This reply in particular: https://mail.mozilla.org/pipermail/rust-dev/2013-May/004182.html -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The 'for' syntax for iterators
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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The future of iterators in Rust
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 it stabilizes. Looking at what other new languages are facing when they start to carry over cruft, I think Rust is at an advantage here to try as much as possible to get things right. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The future of iterators in Rust
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 specifically referring to this issue. Sorry for not being clearer :) I am not really partial to either for syntax proposals. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutability and borrowing
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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Mutability and borrowing
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 because it is also borrowed as mutable
I am guessing this is to avoid aliasing issues? What is the way around this?
Thanks
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutability and borrowing
Thanks everyone. I actually thought about the two suggestions before
posting. I thought there might be some common paradigm for this in the
language though.
So I take it that implementing a += operator overload function would not
have a generic way to handle the case where the same parameter 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 += 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 because it is also borrowed as
mutable
I am guessing this is to avoid aliasing issues? What is the way around
this?
You can copy y instead of passing a reference to it:
fn add_equal(x: mut Complex, y: Complex) { ...
Of course, that means that at the call site, you will have to write
something like add_equal(mut c, copy c).
Unless you want to write a function that just takes one argument and
doubles it, like Abhijeet suggested, I don't know of another way
around this.
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Not a riot, it's a rebellion. -- Boots Riley
Attention Bros and Trolls: When I call out your spew, I'm not angry,
I'm defiant. -- Reg Braithwaite
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Runtime cost of Option
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 assemblies, ut my intuition says that a comparison with None is a single-word check, so it should be pretty fast. Thanks -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon?
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
[rust-dev] Do-notation?
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 = do
x - mx
y - my
return (x + y)
Is there an equivalent construct in Rust?
--
Ziad
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Do-notation?
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
Re: [rust-dev] Calling static methods on type parameters?
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 other / considered more idiomatic? Thanks -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Calling static methods on type parameters?
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: http://blog.pnkfx.org/blog/2013/04/22/designing-syntax-for-associated-items-in-rust/ Niko Interesting. I went through the link above, and both of your blog posts on associated types. Though honestly I can't say I grasped everything :) We will still retain the ability to do have polymorphism on the return type though, correct? (ala let x: Int = parse(123)) Thanks -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Parallelism and concurrency need different tools
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 https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Calling static methods on type parameters?
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 = Newable::new();
x
}
fn main() {
let test : Foo = getOneOfTheseFoo();
}
$ rustc static_type.rs
static_type.rs:19:19: 19:36 error: binary operation cannot be applied to
type `extern Rust fn() - V1`
static_type.rs:19 let test : Foo = getOneOfTheseFoo();
^
static_type.rs:19:19: 19:32 error: cannot determine a type for this bounded
type parameter: unconstrained type
static_type.rs:19 let test : Foo = getOneOfTheseFoo();
^
--
Ziad
On Sun, Apr 28, 2013 at 10:02 PM, Ashish Myles marci...@gmail.com wrote:
Ha! I asked the same question when I first started. I wouldn't be
surprised if this is a common cause of confusion for people coming
from C++ and that name resolution family.
Perhaps notes regarding this could be added to
https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers
?
Ashish
On Wed, Apr 24, 2013 at 3:58 AM, Patrick Walton pwal...@mozilla.com
wrote:
On 4/23/13 10:22 PM, Dylan Knutson wrote:
Hello everyone,
I've been pretty enamored with Rust the past few weeks, and I'm loving
the language so far. However, there is one feature of generics that
doesn't seem to exist in the language, which is being able to call
static methods on type parameters (provided that the type parameter can
be guaranteed to implement it). I'm not all that familiar with
the technical details of the language, so I'm not sure if this is
impossible, or just decided against for some reason. I'm not even sure
if I'm using the terminology correctly, so let me illustrate with some
code:
trait Newable {
fn new() - Self;
}
struct Foo(int);
impl Newable for Foo {
fn new() - Foo {
return Foo(1);
}
}
fn getOneOfTheseT : Newable() - T {
T::new()
}
fn main() {
let test = getOneOfTheseFoo();
}
Inside `getOneOfThese`, try this:
let x: T = Newable::new();
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] automatic dereferences and semicolons
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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 3 Gripes on Rust
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 features I really like about Rust. C++ and D took the implicit approach to pass-by-reference, whereas languages like C# took the explicit approach. Not too long ago, there was a thread on the D forums arguing for making pass-by-reference explicit at the caller site. However, it was too late to make such a backward incompatible change since it would break a lot of code out there. There is no option of having pass-by-reference in Go. You pass a pointer to the struct, which also makes it explicit at the caller site. So in this case, Rust is not dissimilar from Go. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Questions about pointers
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 containing slot, could that be a source of some of the issues in the code? Thanks -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
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 prefixing an
apostrophe on lifetime names is entirely inoffensive.
On Thu, Jan 31, 2013 at 8:58 AM, Niko Matsakis n...@alum.mit.edu wrote:
Interesting. That would indeed address the ambiguity issue.
Niko
Sanghyeon Seo wrote:
UtherII on Reddit /r/rust suggested an idea I like:
{'lt} T
T{'lt}
Basically option 8 of http://smallcultfollowing.com/**
babysteps/blog/2012/12/30/**lifetime-notation/http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
with ' from https://mail.mozilla.org/**pipermail/rust-dev/2013-**
January/002942.htmlhttps://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
This does need a lookahead but as far as I can tell unambiguous and
manageable. More on:
http://www.reddit.com/r/rust/**comments/17ka3b/meeting_**
weekly_20130129_region_syntax_**impl_type/c86t7wghttp://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region_syntax_impl_type/c86t7wg
__**_
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev
__**_
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
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 to wonder how is that lifetime being used? than to wonder what's that thing after the dot? Dean True; however, is it worth to introduce more visual noise in order to be able to make a statement like that in the tutorial? At least the dot operator is not being used for package scopes, like Java or C# for instance. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Tuples and to_str()
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
Re: [rust-dev] Purity by default
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 pure function is never marked impure. That was what I was objecting to. If I misinterpreted I apologize. It seems I may have misunderstood too :P -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rust-0.4 on osx - expected `/str` but found `static/str`
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 pwal...@mozilla.com wrote:
On 10/3/12 7:13 PM, Amitava Shee wrote:
I just built rust from git source on my osx 10.6.8.
amitava$ rustc --version
rustc 0.4 (c3f9b72 2012-09-30 21:35:32 -0700)
host: x86_64-apple-darwin
I am trying to compile the following hello.rs http://hello.rs
fn main() {
let x = [hello,world];
for x.each |y| {
io::println(y);
}
}
I get the following error
amitava:l2 amitava$ make
rustc -g hello.rs http://hello.rs
hello.rs:4:16: 4:17 error: mismatched types: expected `/str` but found
`static/str` (expected /str but found -ptr)
hello.rs:4 http://hello.rs:4 io::println(y);
^
error: aborting due to previous error
make: *** [hello] Error 101
What am I missing?
each now returns a reference, so you want `io::println(*y)`.
Patrick
__**_
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Time to rename the 'unsafe' mods
+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 __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust lightning talk at JavaZone 2012
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 OptionsT (or ResultT, U)-style APIs exist idiomatically through the libraries ... I am still new to using a language with an Option type (I come from an imperative language background,) but wouldn't it be preferable to try to mitigate the number of calls that return an Option type as opposed to returning an actual reference as references cannot be null/nil in Rust? Of course that probably does not apply where an error or failure might happen (such as IO). Thanks, -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Ignore trailing semicolons
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 it is easier to parse visually the way it is now.
--
Ziad
On Wed, Aug 1, 2012 at 7:03 PM, Glenn Willen gwil...@nerdnet.org wrote:
I for one liked the clear and unambiguous rule: semicolon discards value,
no-semicolon returns value.
The idea of allowing uniform semicolon use is appealing, but it does seem
to add complexity and mysteriousness.
FWIW, since I'm not exactly a major player in the Rustiverse currently. :-)
gwillen
On Aug 1, 2012, at 6:53 PM, Patrick Walton wrote:
Hi everyone,
I have a patch that allows trailing semicolons in most cases in Rust
code. This means that code like this will compile:
fn f(x: int) - int {
x + 3;
}
At the moment, this does not compile. You must write:
fn f(x: int) - int {
x + 3
}
For the most part, it does not alter the current rules as to whether
return values can be ignored. Return values can continue to be ignored in
almost all contexts; I didn't have to change any code in the compiler or
standard libraries. Thus this is in practice a backwards-compatible change
intended to eliminate a good deal of toe-stubbing.
There is one subtle source of backwards-incompatibility though: You may
not drop the return value in sugared lambda expressions if you assign them
to a variable (i.e. if the type isn't immediately known). Thus this does
not do what it did before:
// This return value is intended to be ignored.
fn f() - int {
error!(Hi!);
3
}
fn main() {
let g = || { f(); };
error!(%?, g()); // prints 3, not ()
}
I personally feel that this particular gotcha is a small price to pay
for eliminating a frequent source of newcomer frustration, but it is worth
pointing out. Note that this does not apply for downward block closures; if
you're passing a lambda to a function, the return value of the lambda can
be safely ignored as before if the lambda is intended to return unit.
Another downside is that some complexity is added to typechecking; the
typechecker is now aware of statement positions (which are expected to
return unit) and expression positions (which aren't). Note that Scala seems
to have already implemented a rule similar to this, so it isn't without
precedent; it also affects only how HM inference is invoked, not the nature
of unification itself.
I'd like to get feedback as to whether this is a good idea. Comments
welcome!
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
!DSPAM:5019d823101041336712104!
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Bikeshed proposal to simplify syntax
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 compiler, I very much enjoyed the Unix-like, abbreviated names. However, I have to admit that reading Patrick's resolve3 code is making me ashamed of the code I've written lately. I plan to go back and verbos-ify some of my code. I do think it helps with readability overall, though it is definitely true that if names are unnecessarily long (e.g., `ty_param_bounds_and_ty` or `optional_interface`) they can become distracting. Also, our 78-character limit starts to become more of a burden. Niko On 7/17/12 2:39 PM, Patrick Walton wrote: On 7/17/12 2:23 PM, Elliott Slaughter wrote: Now imagine that third-party Rust libraries follow this example. Now I have to learn abbreviations for every library I use in my application. If for any reason I need to modify a third party library for my own purposes, I'll need to learn its internal abbreviations as well. Should we really be using short name everywhere? And if not, how do we encourage people to use readable names, given the example we are providing in the standard library? Agreed. I personally prefer longer, unabbreviated names (and camel-cased types) in user code for this reason. Keywords are a small fixed set of things that all users of the language must know, while user code contains an unbounded number of abbreviations in the limit. See resolve3 for an example of this (although perhaps my names are *too* long there...) In general I'm not a big fan of Unix-command-line-style abbreviation. It works and is elegant when programs are kept very small, but as programs grow larger and larger programmers have to page in and out abbreviations too often for easy reading. Functions like CreateOrRecycleThebesLayer() and UpdateDisplayItemDataForFrame(**) in Gecko may be lengthy, but they sure make digging through MXR easier. Unix was forced to abbreviate for the 6 character limit, but that doesn't exist anymore. In fact, modern Plan 9 code doesn't abbreviate nearly as often as we do; they just pick short names. Take esc.c (just as an example) from Go: http://code.google.com/p/go/**source/browse/src/cmd/gc/esc.chttp://code.google.com/p/go/source/browse/src/cmd/gc/esc.c We have escapes(), visit(), visitcodelist(), visitcode(), analyze(), escfunc(), escloopdepthlist(), escloopdepth(), esclist(), esc(), escassign(), esccall(), escflows(), escflood(), escwalk(), and esctag(). If we assume that the esc prefix is just C namespacing, then the only *abbreviation* there is func. The rest are just short names. The resulting code reads much nicer than the Rust code in our compiler. Short names are fine and read well; abbreviations don't. (In fact, I prefer unabbreviated keywords in general; I'd prefer return, module, and match, but I'm happy to yield to the tastes of the community and BDFL here, since I feel that abbreviated keywords have a much smaller cost than abbreviated user code.) Patrick __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Concurrency and synchronous blocking
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: 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 without bounds? The goroutines would pile up. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Concurrency and synchronous blocking
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 without bounds? Thanks -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
