Re: [rust-dev] RFC: Opt-in builtin traits
On 01/03/14 07:23, Kevin Ballard wrote:
I'm also slightly concerned that #[deriving(Data)] gives the impression that
there's a trait Data, so maybe that should be lowercased as in
#[deriving(data)], or even just #[deriving(builtin)], but this is a lesser
concern and somewhat bike-sheddy.
I guess that Data could actually be a declared as something like:
trait Data : Eq + Clone + ... {}
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] lib: Is anybody working on the datetime library?
I think its great that you are going to be working on this. A comprehensive datetime library is very important. That said I have not got any particular ideas or comments. I have not used Joda time/JSR-310 but the docs look promising and lots of people seem to recommend it. Cheers Gareth On 13/09/13 20:10, Luis de Bethencourt wrote: Hello Bardur, Thank you so much for the reference resource of JSR-310 and its design docs. I looked over it briefly and it is indeed very valuable. It was listed in the wiki page, but the link was to the former home of it. I have updated it. Since nobody has claimed this module, I will start working on this module tomorrow Saturday. Is that OK? Please, please, I would love more comments and ideas. Will start asking for reviews once I have some code to show. Thanks, Luis On 13 September 2013 00:57, Bardur Arantsson s...@scientician.net mailto:s...@scientician.net wrote: On 2013-09-12 22:12, Luis de Bethencourt wrote: Hello everyone, I'm interested in helping with some module development. A good way to learn Rust by using it and help Rust at the same time. Of the wanted modules in this page: https://github.com/mozilla/rust/wiki/Libs I see that this page does have a link to design docs for JSR-310 which is probably a good bet as to a usable DateTime API design (for Java at least). I just thought I'd mention that the documentation for the nearly final (i.e. barring serious bugs) API has been released at: http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html Even if this is for Java, the design decisions about how the conepts of date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) would apply in any language. They are also all essential concepts when working seriously with date/time even though the distinctions may not appear so at first. (I should mention that the lead on the JSR-310 spec was also the author of JodaTime which gets much deserved credit by Java developers for bringing date/time manipulation on the JVM out of the dark ages of java.util.Date. JSR-310 is a slightly reworked/simplified version of that API, so it's a sort of what are the essentials? version of JodaTime.) Regards, ___ Rust-dev mailing list Rust-dev@mozilla.org mailto: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] changing roles
You have done an excellent job. Thank you. Gareth On 31/08/13 01:05, Graydon Hoare wrote: Hi, As I'm sure many of you who know me are aware, my role as technical lead on Rust has been quite draining over the years. Both to myself and to those I've worked with, it just isn't a great fit for me. In recognition of this, I am stepping aside to work elsewhere in the organization, and Brian will be assuming the role of technical lead of Rust. Brian is one of the most skilled, judicious, professional and productive developers I've ever worked with. Along with the exceptional skill and dedication of the rest of the Rust team, I have complete confidence in the remaining path to a successful 1.x series of what has shaped up to be an excellent language. It has been a rare pleasure and privilege to work with the Rust team, both those inside Mozilla and in the broader community. Thanks, -Graydon ___ 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] rustdoc_ng status: all items extracted
Great work, I like the search already. Thanks! On 05/08/13 06:53, Corey Richardson wrote: Hi all, I'm very excited to announce that rustdoc_ng now extracts and jsonifies crates completely in their entirety. Yay! Jordi has been doing some awesome work with the frontend, even adding a search. See http://seld.be/rustdoc/master/index.html, for its current state. There's still a bunch of work to do, but all of it can be implemented with plugins. The cleaned crate is sendable, and in theory it should be generically encodable, but I don't know how to sling extra::serialize, so if anyone could lend a hand with that, that'd be cool. ___ 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] Order of appearance in files of extern mod, mod and use
On 05/08/13 19:56, Dov Reshef wrote:
If I understand correctly mod foo import the foo module into the
current module, and use foo::bar bring bar from foo module into the
current scope, so it seems more logical that use should follow mod,
not the other way around.
My understanding is that mod foo; is kind of like mod foo { ... }
except that with mod foo; the body of the module comes from a
different file, so it is more like a definition than an import.
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Language support for external iterators (new for loop)
One downside of external iterators is that they produce function
signatures that expose implementation details and are harder to understand.
For example, an internal iterator function that loops over odd numbers
would have a signature like this:
fn each_odd(ints: [int], fn(int) - bool) - bool;
The same function written to produce an external iterator would have a
signature more like this:
fn iter_odds'a(ints: 'a [int]) - iterator::FilterMapIterator'a,
int, int, vec::VecIterator'a, int;
This signature is more complicated. It is also likely to change if the
implementation of iter_odds changes (e.g. to no longer use filter_map).
Gareth
On 26/06/13 04:44, Daniel Micay wrote:
This is a followup from the previous discussion on internal vs. external
iterators.[1]
Since then, most iterators in the standard library have been converted to
external ones. Almost all uses of the `for` loop are now using the `.advance`
wrapper, and I don't think there will be any use cases left for the old
internal iteration protocol.
# External iterators
To reiterate the benefits of the external iteration protocol:
* It's generic and works well with traits, so functions can be written to work
on any arbitrary `IteratorA`. Most adaptors can work for any type `A`,
whether it's a value, reference or mutable reference.
* Iteration state is an object, so iterators can be interleaved. This is
required for a generic zip, merge, union, intersect, etc. and is often useful
in an ad-hoc fashion to consume only some of an iterator without
losing it.
* In the future, Rust can have generators using a `yield` statement like C#,
compiling down to a fast state machine without requiring context switches,
virtual functions or even closures. This would eliminate the difficulty of
coding recursive traversals by-hand with external iterators.
# Alternatives
The iteration protocol can't be based on anything requiring virtual method
calls, heap allocations or context switches without the performance becoming
significantly worse.
There have been some suggestions about following the lead of Clojure and using
reducers[2], but the implementation suffers from the same limitations of not
having an external state.
Rust doesn't yet have a way to write data-parallel code, but when it does gain
that, containers can just support partitioning themselves into ranges via
`Iterator`. It will work for in-place mutation in parallel too.
# A new loop
I think it's a foregone conclusion that we'll be replacing `for`, so I suggest
that we just reuse the current syntax and change the semantics:
for iterator |pattern| { body }
This can just be compiled as the following would be:
let mut it = iterator;
loop {
match it.next() {
Some(pattern) = { body }
None = break
}
}
A lang item can be added for the Iterator trait requirement.
This would avoid the `.advance` tacked onto almost every `for` loop at the
moment, and rid us of the problems associated with the current `for`:
* The `break` and `return` statements can fail to work, so borrow/liveness
checking can't trust them. A loop body can't take an `mut` reference and
return it because it could result in grabbing the reference again. This also
seems to be why we forbid `return` inside closures and do statements, since
it
would be confusing to have to act differently than `for`.
* The function's local variables are upvars in the closure, so using them is
very restricted. It's very obvious that it's not just another block because
of this.
* Compiling closures is slow, as they have to broken down by SROA and involve
inlining a function after proving the function pointer is constant. If we
were marking the function pointers as `llvm.invariant` it might stop being a
performance hit, but it would remain a compile time issue.
# Iterables
The `for` loop above can also be extended to work for *any* `Iterable` in the
future, not just iterators themselves.
for iterable |x| { ... } // use the default iterator
for iterable.rev_iter |x| { ... } // use another iterator
At the moment, the `Iterable` trait cannot be defined/used because the compiler
ignores bounds on trait type parameters, but it would be something like the
following:
#[lang = iterable]
trait IterableA, T: IteratorA {
fn iter(self) - T;
}
trait ReverseIterableA, T: IteratorA {
fn rev_iter(self) - T;
}
trait MutableIterableA, T: IteratorA {
fn mut_iter(mut self) - T;
}
trait MutableReverseIterableA, T: IteratorA {
fn mut_rev_iter(mut self) - T;
}
# Links
[1]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html
[2]: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-25#iterators
___
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 12/06/13 15:58, Niko Matsakis wrote:
I imagine that `for expr |pat| { body }` would be syntactic sugar
for:
let mut _iterator_ = expr;
loop {
let pat = match _iterator_.next() {
None = break,
Some(v) = v
};
body
}
I think this is great. It is a more intuitive rewriting than the current
for-loop (where it is not even obvious whether for-loops could be
rewritten without compiler magic).
Arguably retaining the current `for` syntax suggests closures where
none exist, but it seems silly to change it and invalidate all
existing programs for this reason (I imagine `for pat in expr`
would be the more standard syntax).
I don't feel strongly but I think I would prefer `for pat in expr {
... }` because it looks different to a closure and also because it gets
rid of two |. My rust code breaks every time I get the latest incoming
anyway - and it is a pretty mechanical change.
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] bors feature requests
On 25/05/13 20:02, Corey Richardson wrote: On Sat, May 25, 2013 at 2:36 PM, Gareth Smith garethdanielsm...@gmail.com wrote: I am guessing that STALE on http://buildbot.rust-lang.org/bors/bors.html means needs rebase - right? Yes How does a pull request leave the STALE state? Does it have to be reviewed again or will the status update automatically at some point after rebasing? I have rebased https://github.com/mozilla/rust/pull/6433 but it still shows as STALE. It needs to be r+'d again. I see. Thanks. By the time it gets reviewed, though, it will probably already need a rebase... which will require another review, by which time it may need another rebase... There is probably no easy solution to this, but maybe bors can help? Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] bors feature requests
On 10/05/13 01:45, Graydon Hoare wrote: On 13-05-07 08:09 AM, Sanghyeon Seo wrote: Here are some feature requests to bors queue status page at http://buildbot.rust-lang.org/bors/bors.html 3. OUTDATED state, for pull requests that need to be rebased. GitHub API provides mergeable attribute for this. I've fixed #1 and #3 today (as well as adding last-comments and a DISCUSSING state). I'll look into #2 soon. Thanks for the feedback. I am guessing that STALE on http://buildbot.rust-lang.org/bors/bors.html means needs rebase - right? How does a pull request leave the STALE state? Does it have to be reviewed again or will the status update automatically at some point after rebasing? I have rebased https://github.com/mozilla/rust/pull/6433 but it still shows as STALE. Thanks Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Pattern matching binding operator
There might be something obviously wrong with this, but how about:
match foo {
let foo = Foo { field: x } = ...
}
Gareth
On 3 May 2013 02:12, Patrick Walton pwal...@mozilla.com wrote:
Hi everyone,
There's consensus that `@` (imported from Haskell) is a bad binding
operator for patterns, because it leads to the confusing-looking `@@` in,
for example:
struct Foo {
field: int
}
...
match foo {
foo@@Foo { field: x } = ...
}
However, there is not consensus as to what to change it to. Suggestions
are `=` and `as`.
The problem with `=` is that, if implemented naively, it makes our grammar
ambiguous:
let x = y = 3; // is x the result of evaluating `y = 3` (i.e. unit)
// or are x and y bound to 3?
The easiest way to fix this problem is to forbid `=` in irrefutable
patterns, such as those introduced by `let`. However, this bifurcates the
pattern grammar into the irrefutable-pattern grammar and the
refutable-pattern grammar, with some conceptually-ugly overlap.
The alternative is `as`, like OCaml. However, this conflicts with `as` in
the expression grammar. A subset of the expression grammar is part of the
pattern grammar in order to permit matching against constants. Removing
`as` expressions from the subset of expression productions permitted in
patterns would mean that this would no longer do what you expect:
match 22.0f32 / 7.0f32 {
math::PI as f32 = println(Good grief!),
_ = {}
}
So both `=` and `as` have drawbacks.
I don't really have any preference at all; I just need to know what to
implement. Opinions?
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] RFC: syntax of multiple trait bounds on a type parameter
On 11/01/13 18:50, Niko Matsakis wrote:
fn fooT:Eq(..) {...} // One bound is the same
fn fooT:(Ord, Eq, Hash)(...) {...} // Multiple bounds require
parentheses
How about using { ... } rather than ( ... ), like imports:
use xxx::{a, b, c};
fn fooT:{Ord, Eq, Hash}(...) { ... }
I don't know that this is better but maybe it is worth considering?
Gareth.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: impl Trait for Type
I agree it is confusing and that the proposed syntax would probably be
less so.
But, I think that:
impl Trait for Type { ... }
Is still possible to confuse with:
impl Type { ... }
Because they both start with the same keyword. Though perhaps this is
not significant.
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] condition handling
Option 3 looks prettiest to me, but I like that in Option 1 the
error-raising code comes before the error-handling code (based on
experience with other languages). This might not be an issue in practice.
I am not sure how I like Option 3 with a more complex trap block:
OutOfKittens.trap(|t| {
OrderFailure.trap(|t| notify_support()).in {
order_more_kittens();
}
UseAardvarksInstead
}).in {
do_some_stuff();
that_might_raise();
out_of_kittens();
}
Compare this to some ideal syntax:
protect {
do_some_stuff();
that_might_raise();
out_of_kittens();
} handle OutOfKittens(t) {
protect {
order_more_kittens();
} handle OrderFailure(t) {
notify_support();
}
UseAardvarksInstead
)
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.4 released
On 15/10/12 21:31, Graydon Hoare wrote: Mozilla and the Rust community are pleased to announce version 0.4 of the Rust compiler and associated tools. Thanks Graydon and the rest of Mozilla and the others. Rust is shaping up. :) Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal/request to precede variable binding with let in destructuring pattern matching and closures
Hi James, The pattern matching syntax is pretty consistent with Haskell, Ocaml, SML and similar-ish statically typed functional languages. I like it because it is concise and because a pattern is syntactically identical or at least similar to the the value literals that produce the types that it matches. Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On the weirdness of strings
On 05/09/12 21:13, Patrick Walton wrote: On 9/5/12 1:10 PM, Gareth Smith wrote: How about having str be represented internally - but not in the type system - as a pointer to the actual string data. Copying a str would copy the pointed-to string data in addition to the pointer, so str would not be implicitly copyable. Where would the contents be stored? On the the non-task-local (AKA shared?) heap. Graydon wrote: Is this actually a reasonable system? That's what they used to be. People passed them by-value too much and we made too many copies, and balked at the double-indirection implied by passing around an str or such. I was one of those passing them by value too much. I did it because it seemed like the idiomatic thing to do. Even rustc did it - that made it seem legit. It no longer seems like the idiomatic thing to do because the compiler emits a warning about it unless it is done explicitly, so I try to avoid it. I think that documentation and compiler warnings will determine typical use. That also doesn't handle the fixed-size, constant-memory and substring-slice use-cases. Fair enough. The current scheme is a very delicate balance between a large number of pressures; I think it's about the best we're going to get. The problem with rust's strings is that any rust program I write seems to be more complicated because of features that strings have that 99% of the time I will not use. I have to pay for safe concurrency even though it looks like I will barely be using it. Ditto with fixed size and constant memory strings. You created a nice language for programs that are mostly non-concurrent (regardless of how nice it is for highly concurrent programs), so I and others are going to try using it for that :) ... and sometimes wondering why the strings are so hard to use. I don't know what the fix is, but I think this issue is going to keep coming up, because I think *for some people* there is a better balance to be had. Thanks Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Naming conventions for constructors
Hi,
I guess this is also an issue when type names are used in non-constructor
functions: e.g. should the to_str method actually be called to_Str, should
to_bytes be called to_Bytes ?
I think the new convention looks OK, but it is a bit weird with multiple
constructors in a module because you then have to include the type name in
the function name.
I am curious what the motivation is for changing the naming convention of
types?
Thanks
Gareth
On 15 August 2012 02:24, Brian Anderson bander...@mozilla.com wrote:
On 08/14/2012 06:04 PM, Erick Tryzelaar wrote:
On Tue, Aug 14, 2012 at 4:35 PM, Brian Anderson bander...@mozilla.com
wrote:
Hey.
Hello.
:)
Then to use it:
import my_crate::belt_buckle;
let my_belt_buckle = belt_buckle::new();
You will mostly not import the constructor because it will need to be
disambiguated from all the other 'new's in the world.
This is fine with me, I liked this style back in the pre-typeclass
rust. There were two things that bugged me about this style. First,
impls made import lines pretty dense, so it was nice to just import
one type/impl/fn. Is this still the case with the new min/max classes?
The situation is much better with impls now. Any impls defined in the same
module as the type are automatically available everywhere. The current
scheme is nice in that you import `dvec::dvec` and get both the type and
the constructor.
Second, If I wanted to import anything from the module, I'd have to
write:
import my_crate::belt_buckle;
import my_crate::belt_buckle::**BeltBuckle;
Maybe we could add some sugar to combine those two lines into (forgive
me if there's already a way to do this):
import my_crate::belt_buckle::{., BeltBuckle};
Something like this does seem appropriate.
__**_
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] Naming conventions for constructors
On 15/08/12 20:31, Brian Anderson wrote: There are two reasons that I can recall off-hand... That sounds reasonable. Thanks. Gareth. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Ignore trailing semicolons
Thus this is in practice a backwards-compatible change intended to
eliminate a good deal of toe-stubbing.
IMHO the source of the toe-stubbing may be that rust has so many different
ways to return a value:
fn f() - int { 42 }
or
fn f() - int { ret 42 }
or
fn f() - int { ret 42; }
And ret cant be used inside lambdas. Except in do/for blocks.
This proposal would add another variant:
fn f() - int { 42; }
Most curly brace languages have just one way to return a value:
int f() { return 42; }
I would rather that I did not have to make the choice about which syntax to
use. It doesn't seem like a meaningful choice.
Gareth
On 2 August 2012 02:53, Patrick Walton pwal...@mozilla.com 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-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] mode removal
On 26/07/12 21:54, Niko Matsakis wrote: Summary: we plan to make it possible for you to call methods on a variable of type `fat` even if those methods are defined on `fat`. But it doesn't work yet... Thats interesting. Thanks for the explanation. Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] mode removal
On 25/07/12 21:11, Graydon Hoare wrote:
... the borrowed-pointer-using code looks like so: ...
Thanks for the clarification. That makes sense.
Can I have another clarification please. I have some rust code currently
that looks like this:
// a type that should not be copied implicitly because it is mutable
class fat {
let mut doughnuts: int;
new(){
self.doughnuts = 99;
}
}
trait fat_methods {
fn shizzle();
}
impl of fat_methods for fat {
fn shizzle() {
io::println(yo shizzlin);
}
}
fn main() {
let x = fat();
x.shizzle();
}
One way to change this code would be to make the impl for fat rather
than for fat, and change x's expression to fat(). Luckily this also
seems to allow calling methods on @fat and ~fat types. Is this a
reasonable way to migrate the code? Are their alternatives?
Thanks
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Dealing with ` illegal borrow unless pure` errors
On 08/07/12 03:35, Niko Matsakis wrote:
Your recent e-mail reminded me that I never responded to this one.
Sorry about that, I was on vacation.
No problem. You deserved a vacation with all the work you are doing on rust.
In general I think the most widely applicable answer is that if you
want to put an enum into a mutable field, just make sure that it is
cheaply copyable. So don't have `optionmy_big_record` but rather
`option@my_big_record`. This is probably a good idea anyway, since
you don't want to be copying big things around all the time.
I think that makes sense.
Is there potential for the copy to be cheap enough to use
`optionT` (without the pointer)? I feel that by-copy is simpler to
reason about and also easier to read/write.
I don't know what's best. We may want to have two functions/methods,
one which expects a pointer and one which doesn't. The copy of an
optionT is not inherently expensive: its cost will naturally depend
on T. Certainly we want a *optionT variant for those cases where T
is something prohibitively expensive to copy, such as a unique
pointer, or where it has identity.
We may want both versions for other reasons. In the mode world, it is
common to run up against mode mismatches: the function is declared
with mode ++, for example, but is being used in a context where is
required. The equivalent in a region world would be a function that
expects T being used in a context where *T is expected. It's also
possible we could write a generic conversion wrapper to deal with this
situation, something like:
fn to_valT,U(f: fn(T) - U, x: *T) - U { f(*x) }
I can't claim to know what is best either. Hopefully it will become more
obvious over time, especially if/when argument modes are removed (please!).
Thanks
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Dealing with ` illegal borrow unless pure` errors
On 24/06/12 19:51, Niko Matsakis wrote:
Are there other ways of fixing the issue?
There is one other way. You can restructure the caller. The most
ambitious would be to change the field from mutable to immutable, but
often that does not work. In that case, you can also update the type
of the record from @{mut f: optionT} to @{mut f: @optionT}. You
would then call the function with `*r.f` (where `r` is the record).
This is permitted because, while the `f` field is mutable, the field
does not store the option but rather a pointer to the option. The
*option itself* is stored in immutable memory (that is, the @ box).
This means putting wrapping every mutable field *of a type not passed by
value* inside a shared box (because every mutable field might need
passing to a function). This means that updating the field requires
memory allocation, and reading the field requires following a pointer
indirection. This seems disproportionately expensive.
If these concerns are real (I think they are but I don't that much about
rust) then surely there is a better solution?
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Integer literal suffix inference
Hurrah! Thank you. Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Dealing with ` illegal borrow unless pure` errors
Thanks for the response Niko,
There is one other way. You can restructure the caller. The most
ambitious would be to change the field from mutable to immutable, but
often that does not work. In that case, you can also update the type
of the record from @{mut f: optionT} to @{mut f: @optionT}. You
would then call the function with `*r.f` (where `r` is the record).
This is permitted because, while the `f` field is mutable, the field
does not store the option but rather a pointer to the option. The
*option itself* is stored in immutable memory (that is, the @ box).
This makes sense. However I feel it encourages me to wrap all mutable
record/class fields in @ boxes, which to me seems awkward to read/write
and probably inefficient too.
I also have read that argument modes are being removed. How will
that affect this situation?
Probably not at all. What will happen is that the argument will
change from being mode and type optionT to type *optionT (or
^optionT, whichever syntax we choose).
If the single remaining argument mode is by-copy, does that mean
this issue will go away?
The problem goes away if the parameter type is `optionT`---but I
would guess that in practice the type will be `*optionT` to avoid
the copy.
Is there potential for the copy to be cheap enough to use `optionT`
(without the pointer)? I feel that by-copy is simpler to reason about
and also easier to read/write.
Thank You
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Dealing with ` illegal borrow unless pure` errors
Hi rust-dev,
How should these errors be dealt with?
For example, given the following code:
fn takes_an_option(_x: optionint) {}
fn takes_a_rec(x: @{mut a: optionint}) {
takes_an_option(x.a);
}
fn main() {
let x = @{mut a: some(4)};
takes_a_rec(x);
}
rustc produces:
test.rs:6:20: 6:23 error: illegal borrow unless pure: creating immutable
alias to aliasable, mutable memory
test.rs:6 takes_an_option(x.a);
^~~
test.rs:6:4: 6:19 note: impure due to access to impure function
test.rs:6 takes_an_option(x.a);
^~~
error: aborting due to previous error
I can think of 3 ways of fixing the issue:
1. Declaring takes_an_option as pure. This can't be done in a library
controlled by
someone else, though, and it also can't be done if the function isn't
actually pure.
2. Declaring the argument mode for takes_an_option to be ++ (pass by
copy). Again
this can only be done if the library isn't someone else's, but I can't
see any other
downsides apart from more sigil-filled source code.
3. Copying the argument explicitly when invoking the function:
takes_an_option(copy a.x);
This doesn't require owning the library.
Are there other ways of fixing the issue?
I also have read that argument modes are being removed. How will that
affect this situation?
If the single remaining argument mode is by-copy, does that mean this
issue will go away?
Thanks
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Block lambda syntax tweak
On 07/06/12 22:27, Patrick Walton wrote:
If you allow all block lambdas to have early returns with ret, then
this:
fn f() {
for int::range(1, 10) |i| {
ret i;
}
}
Has a very different meaning from:
fn f() {
int::range(1, 10) |i| {
ret i;
}
}
IMHO this is likely to be pretty confusing.
Fair enough, I can see where you are coming from.
Also, eliminating do makes this ambiguous:
spawn() || {
...
}
Is ambiguous with bitwise-or. This is also ambiguous:
spawn || {
...
}
As I understand it, given point 2 of the proposal, the above code would
not be valid. Instead it would look like:
spawn(|| {
...
});
Is that correct? If so, would the semantics of the directly above be
identical to:
do spawn {
...
}
?
-Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Doc-comment syntax
On 02/06/12 16:17, Patrick Walton wrote: I agree completely and have thought the exact same thing in the past. I will bring this up at the next meeting. On 04/06/12 01:52, Brian Anderson wrote: Agreed on all points. The current syntax was just an expedient to get rustdoc working, and the intent has been to revisit exactly how we feed that information into rustdoc. Thats great. Thanks. Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Doc-comment syntax
Dear Rust developers/users,
I want to convince you that the current syntax for doc-comments in rust
is sub-optimal and should be re-worked.
Here is an example of a doc-comment in various languages:
Rust:
#[doc = Some short description of what this function does]
fn my_fun (x: int) - int { ... }
Python:
def my_fun(x):
Some short description of what this function does
Java:
/**
* Some short description of what this function does
*/
int myFun (int x) { ... }
I feel that the syntax for Rust is more complex than in Python/Java. The
programmer has more rules to follow when reading/writing it. The difference
is small, only a paper-cut, but please consider that:
1. Compared to Python/Java, it takes more effort to read/write Rust's
doc-comments
and therefore fewer people will do so.
2. When people are spending less effort on doc-comments then they can spend
more effort on their real job. Tasks that take less effort feel more
fun.
3. doc-comments are a frequently used part of the language, so a special
syntactic form is justified over using the generic attribute syntax.
Proposed solution:
I suggest that the current doc-comment syntax be replaced with:
/// ... (three slashes instead of two) for single line doc-comments
/** ... */ (two initial stars instead of one) for multi-line doc-comments
In this scheme doc-comments are just normal comments with some - very
lightweight - marker syntax that lets the programmer/text-editor know that
they are special. It is similar to Java and some C++ commenting standards.
Does this proposal have any hope?
Thanks
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Removing `as` (a WIP)
On 10/05/12 15:57, Graydon Hoare wrote: I'm a little nervous about what you're proposing here. I think enums can probably be done with a sys::enum_valueT intrinsic that fails to compile on non-enums. Or something involving the reflection interface I'm currently building. I don't think this part is a blocker. Just a thought - how about `sys::enum_valueT:c_enum(x: T) - uint` where c_enum is some new kind given only to c-style enums? Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Removing `as` (a WIP)
On 10/05/12 15:57, Graydon Hoare wrote: I'm a little nervous about what you're proposing here. I think enums can probably be done with a sys::enum_valueT intrinsic that fails to compile on non-enums. Or something involving the reflection interface I'm currently building. I don't think this part is a blocker. Just a thought - how about `sys::enum_valueT:c_enum(x: T) - uint` where c_enum is some new kind given only to c-style enums? Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Bikeshed impl method extraction
On 30/04/12 07:08, Steven Blenkinsop wrote:
On Sunday, April 29, 2012, Gareth Smith wrote:
Hi,
I have written up some thoughts about a enabling a less
repetitious API for constructing hashmaps (amongst other
possibilities), here:
https://github.com/mozilla/rust/wiki/Bikeshed-impl-method-extraction
Does this make any sense?
Couldn't you just do something like:
fn hashmap K:hash equals copy, V:copy () - std::map::hashmapK, V {
ret std::map::hashmap({|k| k.hash()}, {|k1,k2| k1.equals(k2)});
}
?
Ah, I had not considered that - and it looks to me like it should work -
but it doesn't:
hello.rs:26:31: 26:37 error: the type of this value must be known in
this context
hello.rs:26 ret std::map::hashmap({|k| k.hash()}, {|k1, k2|
k1.equals(k2)});
but this might be a type inference bug, because if it is rewritten with
type annotations then it works:
let hashfn:fn@(K)-uint = {|k| k.hash()};
let eqfn:fn@(K, K)-bool = {|a, b| a.equals(b)};
ret std::map::hashmap(hashfn, eqfn);
Considering your answer, and the other answers, I have abandoned this
bikeshed.
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Bikeshed impl method extraction
Hi, I have written up some thoughts about a enabling a less repetitious API for constructing hashmaps (amongst other possibilities), here: https://github.com/mozilla/rust/wiki/Bikeshed-impl-method-extraction Does this make any sense? Gareth ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
