Here's one use case your proposal doesn't cover:
Subtracting two points returns a vector, which either has the same internal
representation as a point or uses point as its internal representation, and
thus, despite the return type of the subtraction operation being different from
`Self`, it's
moved away, then it means
that you didn't intend to move the data away in the first place, but to clone
it. And vice versa.
On 2014-06-12, at 21:15, Patrick Walton pcwal...@mozilla.com wrote:
On 6/12/14 11:15 AM, Tommi wrote:
On 2014-06-12, at 20:59, Corey Richardson co...@octayn.net
mailto:co
As it stands, the documentation doesn't say that `Mul` means commutative
multiplication. Therefore it would be a mistake to write generic code that
assumes that a type which implements `Mul` has commutative multiplication.
Implementing `Mul` for two matrices would not be a mistake.
On
On 2014-06-15, at 21:10, Isaac Dupree m...@isaac.cedarswampstudios.org wrote:
On 6/12/14 11:15 AM, Tommi wrote:
But I think it will be easy to make the error of writing the explicit
.clone() in places where it's not needed. For example:
[...]
Would a compiler warning for unnecessary clones
I wrote my suggestion as RFC #124
https://github.com/rust-lang/rfcs/pull/124
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 2014-06-15, at 9:56, Benjamin Striegel ben.strie...@gmail.com wrote:
You're welcome to draft a proposal if you think that you have an idea to make
this possible.
The idea of the `stable` keyword was designed specifically as a bandage on the
current trait-system to allow a trait to say
I realized that, in my proposal, there's a potentially pretty confusing
asymmetry of what `stable` means. In the trait definition:
pub trait MulRHS, Result {
fn mul(stable self, rhs: RHS) - Result;
}
...the keyword `stable` means that however the type which implements this trait
decides to
I think that the deeper and larger language design issue here is that traits in
some cases force you to impose on the trait-implementing type some
implementation details that should remain hidden in the specification of the
trait and should be left to the trait-implementing type to specify.
The problem:
Chained calls to certain operators such as binary `*` and `+` may cause
unnecessary memory allocations. For example:
struct Vector {
coordinates: Vecint
}
impl Mulint, Vector for Vector {
fn mul(self, rhs: int) - Vector {
let mut new_coordinates =
On 2014-06-13, at 13:14, Tommi rusty.ga...@icloud.com wrote:
pub trait MulRHS, Result {
fn mul(stable self, rhs: RHS) - Result;
}
Note: any other syntax for marking `self` as `stable` would be illegal.
Although, I could see this kind of syntax being allowed as well:
pub trait MulRHS
On 2014-06-11, at 16:27, SiegeLord slab...@aim.com wrote:
So, I think the situation is pretty bad. What can be done to fix it?
I agree that this seems like a serious regression from C++. If it won't be
fixed, I think I'll rather stick with C++. Better the devil you know...
On 2014-06-12, at 19:08, Patrick Walton pcwal...@mozilla.com wrote:
On 6/11/14 6:27 AM, SiegeLord wrote:
So, I think the situation is pretty bad. What can be done to fix it?
Seems to me we can just make the overloaded operator traits take by-value
self.
I definitely wouldn't want to see
I think a new keyword, something like `stable`, is needed for specifying that
an argument passed to a trait function is guaranteed to be logically unchanged
after the function call. For example:
trait Foo {
fn foo(stable self);
}
impl Foo for int {
fn foo(self) {} // OK
}
impl Foo for
{ ... }`.
On Thu, Jun 12, 2014 at 10:26 AM, Tommi rusty.ga...@icloud.com wrote:
I think a new keyword, something like `stable`, is needed for specifying
that an argument passed to a trait function is guaranteed to be logically
unchanged after the function call. For example:
trait Foo {
fn foo
On 2014-06-12, at 20:51, Patrick Walton pcwal...@mozilla.com wrote:
On 6/12/14 10:46 AM, Tommi wrote:
`Copy` types aren't really relevant to a discussion about adding to
Rust the C++ like optimization of moving rvalues (of non-Copy types)
when they're passed to certain functions.
There's
On 2014-06-12, at 20:59, Corey Richardson co...@octayn.net wrote:
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable and would require adding Clone to the
language (it's currently a normal library feature).
But I think it will be easy to make the
On 2014-06-12, at 21:15, Patrick Walton pcwal...@mozilla.com wrote:
On 6/12/14 11:15 AM, Tommi wrote:
On 2014-06-12, at 20:59, Corey Richardson co...@octayn.net
mailto:co...@octayn.net wrote:
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable
For some reason I got really side-tracked here. The whole point of that
`stable` keyword I proposed was not syntax sugar, but that it allows the
implementor of such a trait to pass by reference when the operator shouldn't
move the passed in argument(s). Like, when you multiply two matrices and
If the `Mul` trait and similar were changed to take `self` by value, perhaps
the following kind of language design would make more sense:
If a variable of a type that has a destructor is passed to a function by value
(moved), and the variable is used after the function call, the variable would
On 2014-06-11, at 21:33, Daniel Micay danielmi...@gmail.com wrote:
Cloning big integers, rationals based on big integers or arbitrary
precision floating point values for every single operation has a high
cost.
I didn't say that all functions should start taking their arguments by value. I
On 2014-06-11, at 21:47, Tommi rusty.ga...@icloud.com wrote:
I said `Mul` and similar should do it, i.e. functions that take a variable
and return a variable of that same type.
Although, a larger issue of genericity is that multiplication doesn't always
return the same type as one of its
Due to a lack of objections, I made an RFC at:
https://github.com/rust-lang/rfcs/pull/108
On 2014-06-03, at 19:56, Gulshan Singh gsingh_2...@yahoo.com wrote:
+1, I was planning on suggesting this as well.
On Jun 3, 2014 2:16 AM, Tommi rusty.ga...@icloud.com wrote:
I find it somewhat
I don't know if there's a better way, but this at least works:
let tmp: Testbool = Test::new();
let t = tmp.test();
println!(t={}, t);
On 2014-06-04, at 10:28, Igor Bukanov i...@mir2.org wrote:
What is the syntax for calling a static method of a generic struct
while selecting the the generic
Apparently this works as well:
let t = Test::bool::new().test();
println!(t={}, t);
On 2014-06-04, at 10:50, Tommi rusty.ga...@icloud.com wrote:
I don't know if there's a better way, but this at least works:
let tmp: Testbool = Test::new();
let t = tmp.test();
println!(t={}, t
I find it somewhat jarring to have to spend two lines for the following kind of
imports:
use module::Type;
use module;
So, I suggest we add a nicer syntax for doing the above imports using the
following single line:
use module::{self, Type};
It would probably be a good idea to force the
In my original post I stated that it feels like there's something wrong with
the language when it doesn't allow multiple mutable references to the same
data, but I didn't really explain why it feels like that. So, I just want to
add this simple example to help explain my position. It is just
On 2014-06-02, at 10:44, Tommi rusty.ga...@icloud.com wrote:
Nothing can go wrong here [..]
I just watched this video https://www.youtube.com/watch?v=awviiko59p8 and now I
get the impression is that perhaps preventing aliasing bugs is more important
than the convenience of unrestricted
Would it be possible to get a compile-time error for a `match` branch that can
never be reached due to a previous branch encompassing it. For example, for the
middle branch here:
let n = 0;
match n {
x if x 2 = (),
x if x 1 = (),
_ = ()
}
If this is a too complicated a problem in
On 2014-06-01, at 13:48, Gábor Lehel glaebho...@gmail.com wrote:
It would be possible in theory to teach the compiler about e.g. the
comparison operators on built-in integral types, which don't involve any user
code. It would only be appropriate as a warning rather than an error due to
the
On 2014-05-31, at 22:13, Matthieu Monrocq matthieu.monr...@gmail.com wrote:
Another example of memory issue:
foo(left: OptionBoxstr, right: mut OptionBoxstr) {
let ptr: str = *left.unwrap();
right = None;
match ptr.len() { // Watch out! if left and right
On 2014-05-31, at 20:44, Patrick Walton pcwal...@mozilla.com wrote:
On 5/31/14 10:36 AM, Tommi wrote:
Iterator invalidation (as it's known in C++) is a risk to memory
safety only when some of the memory that is accessible through an
iterator (or a reference) is deallocated. A better type
On 2014-06-01, at 1:02, Patrick Walton pcwal...@mozilla.com wrote:
fn my_transmuteT:Clone,U(value: T, other: U) - U {
let mut x = Left(other);
let y = match x {
Left(ref mut y) = y,
Right(_) = fail!()
};
*x = Right(value);
On 2014-06-01, at 2:45, Huon Wilson dbau...@gmail.com wrote:
References (T) are Copy.
That didn't occur to me. Okay, I can see how that would be a problem.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 2014-05-30, at 4:16, Eric Reed ecr...@cs.washington.edu wrote:
That was what I was referencing in my comment about the compiler getting
scared and confused. Theoretically, it should be allowed and the compiler
would just require you to specify, but rustc may not be there yet.
Are you
The manual says that the precedence of `as` operator is lower than that of the
binary `*` operator. Thus I would not expect the following to compile (but it
does):
let a: u16 = 1;
let b: u32 = 2;
let r = a * b as u16;
Since multiplication is supposed to have precedence over casting, I would
On 2014-05-30, at 2:48, comex com...@gmail.com wrote:
On Thu, May 29, 2014 at 7:01 PM, Tommi rusty.ga...@icloud.com wrote:
The lack of function overloading forces us to have two differently named
functions, say `foo_a` and `foo_b`, and the programmer has to keep in mind
that if he wants
On 2014-05-30, at 3:42, Eric Reed ecr...@cs.washington.edu wrote:
Rust *does* have function overloading. That's *exactly* what traits are for.
If you want to overload a function, then make it a trait and impl the trait
for all the types you want to overload it with.
I've been trying to
On 2014-05-30, at 3:28, comex com...@gmail.com wrote:
On Thu, May 29, 2014 at 8:21 PM, Tommi rusty.ga...@icloud.com wrote:
Assuming the programmer knows both the type of the argument and the manner
in which the type of the argument determines which algorithm ends up being
used
Could we add to the standard library a macro, say 'include_sized_bin', that
would be similar to std::macros::builtin::include_bin except that you'd also
give it a sized type to return (instead of a slice of u8's) and you'd get a
compile time error if the size of the file is different from the
...@sb.org wrote:
What's the use-case for this?
-Kevin
On May 27, 2014, at 3:24 AM, Tommi rusty.ga...@icloud.com wrote:
Could we add to the standard library a macro, say 'include_sized_bin', that
would be similar to std::macros::builtin::include_bin except that you'd also
give
at 10:27 AM, Tommi rusty.ga...@icloud.com wrote:
What is the meaning of this 'box ref foo' syntax found in the tutorial over
at __http://doc.rust-lang.org/tutorial.html#references
(Sorry for uglifying the link, my posts seem to get flagged as spam if they
contain links)
In short, it's
What is the meaning of this 'box ref foo' syntax found in the tutorial over at
http://doc.rust-lang.org/tutorial.html#references
In short, it's:
enum Shape { Sphere(Boxf32) }
let shape = Sphere(box 1.0f32);
let r = match shape {
Sphere(box ref radius) = *radius
};
I thought the 'box'
On 2014-05-17, at 3:54, Kevin Ballard ke...@sb.org wrote:
On May 15, 2014, at 9:54 PM, Daniel Micay danielmi...@gmail.com wrote:
On 16/05/14 12:48 AM, Tommi wrote:
On 2014-05-16, at 7:35, Steven Fackler sfack...@gmail.com wrote:
Type annotations are not there for the compiler; they're
I was just wondering, why do we have to explicitly specify the lifetimes of
references returned from functions? Couldn't the compiler figure those
lifetimes out by itself by analyzing the code in the function?
___
Rust-dev mailing list
On 2014-05-16, at 7:14, Daniel Micay danielmi...@gmail.com wrote:
On 16/05/14 12:10 AM, Tommi wrote:
I was just wondering, why do we have to explicitly specify the lifetimes of
references returned from functions? Couldn't the compiler figure those
lifetimes out by itself by analyzing
No one?
I understand that a part of the reason the RFC process is made so complex is
that it filters out idiots like me. But I think this one is a pretty important
design choice that Rust is about to get wrong.
On 2014-04-18, at 6:27, Tommi rusty.ga...@icloud.com wrote:
Could someone please
(which I did manage to create and
make the pull request in it, although the intermediate step of moving a file
became part of the pull request when it shouldn't have):
https://github.com/TommiT/rfcs
On 2014-04-22, at 16:52, Flaper87 flape...@gmail.com wrote:
2014-04-22 15:45 GMT+02:00 Tommi
On 2014-04-22, at 21:44, Brian Anderson bander...@mozilla.com wrote:
I'm not sure what you are asking for here. Have you submitted this as a pull
request to http://github.com/rust-lang/rfcs?
No, I haven't made the pull request, because I don't know how to do that (or
perhaps I would know how
On 2014-04-17, at 11:25, Marvin Löbel loebel.mar...@gmail.com wrote:
Would you mind me taking this RFC over and including it into my proposal?
Yes please, by all means. I'm looking forward to your proposal.
But actually I just realized that my proposal is essentially just a syntax
sugar for a
Can someone explain me why the module system maps to the file system in the way
it does? The problem is that you can end up with these modules named mod.rs
instead of the more informative names. If you have the following modules:
foo
foo::lut
bar
bar::lut
...that maps to files and folders as
Okay, thanks for explaining the reasoning. I think I'll conform to the standard
way of doing things.
On 2014-04-17, at 18:56, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Apr 17, 2014 at 05:39:15PM +0300, Tommi wrote:
...but why not map such modules to files and folders as the following
Could someone please commit this RFC for me, thank you:
- Start Date: 2014-04-18
- RFC PR #:
- Rust Issue #:
# Summary
I propose the ability to set trait items (i.e. just methods currently) private
as well as public in order to expand the scope of possible use cases of
provided methods (i.e.
I can't figure out how GitHub works, so can someone please commit the following
RFC, thank you:
- Start Date: 2014-04-17
- RFC PR #:
- Rust Issue #:
# Summary
Add the ability to specify that a type, which implements a certain trait, must
have certain set of fields (data members) of certain
On 2014-04-16, at 4:34, Daniel Micay danielmi...@gmail.com wrote:
On 15/04/14 09:20 PM, Tommi wrote:
Disclaimer:
I don't know the current status of 'assert' macro, but for the duration of
this post I'll assume that it's going to change into a sanity-checking tool
and will get compiled away
On 2014-04-16, at 4:39, Brandon Sanderson singingb...@gmail.com wrote:
In general, I'd be against allowing disabling of something like 'enforce!'.
The whole point of using such a macro would be to say Never let this be
false. If it is, fail so that it can't cause bigger problems. Your
On 10 Apr 2014, at 07:53, Kevin Ballard ke...@sb.org wrote:
On Apr 9, 2014, at 9:50 PM, Tommi Tissari rusty.ga...@icloud.com wrote:
On 10 Apr 2014, at 00:22, Kevin Ballard ke...@sb.org wrote:
FWIW, my point about range is it relies on One being the number 1, rather
than being
.
On 10 Apr 2014, at 09:27, Kevin Ballard ke...@sb.org wrote:
On Apr 9, 2014, at 11:25 PM, Tommi Tissari rusty.ga...@icloud.com wrote:
On 10 Apr 2014, at 07:55, Corey Richardson co...@octayn.net wrote:
range doesn't return a forward iterator. RangeA also implements
DoubleEndedIterator
to renaming num::One to MultiplicativeIdentity
as well (as it pertains to symbol 1 denoting multiplicative identity).
If those names are too long, the shortened AddIdentity and MulIdentity could be
used instead.
On 10 Apr 2014, at 00:06, Tommi Tissari rusty.ga...@icloud.com wrote:
On 09
:
On Apr 7, 2014, at 1:02 AM, Tommi Tissari rusty.ga...@icloud.com wrote:
On 07 Apr 2014, at 08:44, Nicholas Radford nikradf...@googlemail.com
wrote:
I think the original question was, why does the zero trait require the add
trait.
If that was the original question, then my answer would
On 09 Apr 2014, at 20:46, Kevin Ballard ke...@sb.org wrote:
For reference, the Zero trait lives in std::num, which should be a good
indication that this is a property of numeric types.
Am I not supposed to use std::num::Zero for defining things like zero vector or
zero matrix? Those are
On 09 Apr 2014, at 20:46, Kevin Ballard ke...@sb.org wrote:
Why? Zero is the additive identity.
Zero is _an_ additive identity for numbers, but not for vectors or matrices.
use std::slice::Items;
use std::iter::RandomAccessIterator;
use std::num::Zero;
Items is a RandomAccessIterator, but a
On 10 Apr 2014, at 00:22, Kevin Ballard ke...@sb.org wrote:
FWIW, my point about range is it relies on One being the number 1, rather
than being the multiplicative identity. AFAIK there's nothing special about 1
in a ring outside of its status as a multiplicative identity. Certainly it's
I just realized that this 'Invalid' trait is also a prime example of why traits
must be able to specify their items as private. Obviously that 'invalid' static
method / constant should not be part of the public interface. Heck, the sole
reason for the existence of the type could be that it
a value can have a zero value
have to do with adding numbers.
In other words, it is possible for something to have a zero value without
requiring addition, so why does the Zero trait not reflect this.
On 6 Apr 2014 12:29, Tommi rusty.ga...@icloud.com wrote:
The tutorial (17.7) says
The tutorial (17.7) says the following:
We can write a trait declaration that inherits from other traits, called
supertraits. Types that implement a trait must also implement its supertraits.
Since num::Zero inherits from AddSelf, Self, you must implement it (the
supertrait) also.
On
On 2014-04-04, at 12:30, Vadim Chugunov vadi...@gmail.com wrote:
trait Invalid {
fn invalid() - Self;
}
The compiler could then perform option space optimization for any type
implementing 'Invalid'.
I just realized that Rust already uses static methods just like the one you
suggested
Richardson co...@octayn.net wrote:
Language suggestions should go through our new RFC process:
https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md
On Thu, Apr 3, 2014 at 8:26 PM, Tommi rusty.ga...@icloud.com wrote:
I forgot to mention that this same space-optimization
On 04 Apr 2014, at 12:30, Vadim Chugunov vadi...@gmail.com wrote:
Regarding the original idea: Why use a whole bit, when you only need one
value out of all possible type's values? For example, for floats, one of
the NaNs could be used for this purpose without any issues with overflow as
I have a suggestion. Let's add new primitive data types:
i7, i15, i31, i63, u7, u15, u31, u63, f31 and f63
Those would behave exactly like the integral data and floating-point data types:
i8, i16, i32, i64, u8, u16, u32, u64, f32 and f64
...except that the new data types would come with the
I forgot to mention that this same space-optimization could be done for
Optionbool already.
On 2014-04-04, at 03:18, Tommi rusty.ga...@icloud.com wrote:
I have a suggestion. Let's add new primitive data types:
i7, i15, i31, i63, u7, u15, u31, u63, f31 and f63
Those would behave exactly
Vector uses the word last to denote the last element, whereas collections and
iterators use the word back. I'd like to see consistent naming of these
things, like front and back for bounds that are included in the set, and
ahead and behind for bounds which are excluded from the set.
On 28 Mar 2014, at 05:48, Daniel Micay danielmi...@gmail.com wrote:
I don't know about those other dialects.
You're proposing introducing new dialect of Rust.
In Crust, code generating a failure on out-of-bounds will now cause
silent memory corruption. Crust will do away with safety
On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote:
I think that Rust should give you the ability to opt out of safety, but on a
per-operation basis. Having it as a compiler option is too much of a
sledgehammer: often you want some non-performance-critical bounds to be
On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote:
On 28/03/14 08:25 AM, Tommi wrote:
On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote:
I think that Rust should give you the ability to opt out of safety, but on
a per-operation basis. Having
On 28 Mar 2014, at 15:01, Huon Wilson dbau...@gmail.com wrote:
[..] And anyway, as Daniel and Patrick say, if you don't need the utmost
safety, then Rust isn't the language you're looking for: things like C++ work
well in the speed department, at the cost of safety
Yes, it seems that Rust
On 28 Mar 2014, at 17:46, Erick Tryzelaar erick.tryzel...@gmail.com wrote:
Disagreement is fine [..]
I would think that to be an axiom which didn't need to be mentioned.
What I think this whole discussion boils down to, is orthodoxy vs. pragmatism.
The pragmatic think that wiggle room is
On 28 Mar 2014, at 14:47, Daniel Micay danielmi...@gmail.com wrote:
On 28/03/14 07:44 AM, Tommi wrote:
This is incorrect. All those range based functions (or majority of
them... I'm not sure) are safe if the range(s) you pass to them is safe.
That's why those range functions can't guarantee
On 28 Mar 2014, at 15:43, Matthew Frazier leafstormr...@gmail.com wrote:
I would just like to interject that this conversation has been blowing my
inbox up all morning and seems to be going absolutely nowhere.
That's a good argument against using mailing lists for this kind of a purpose.
[The following post has nothing to do with thread. I'm posting it here because
my new posts to this mailing list don't go through (this happens to me a lot).
Replies to existing posts tend to go through, thus I'm hijacking my own thread.]
Title: Compiling with no bounds checking for vectors?
On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote:
Why isn't there a compiler flag like 'noboundscheck' which would disable all
bounds checking for vectors? It would make it easier to have those language
performance benchmarks (which people are bound to make with no bounds
should be allowed to make for himself. A bit
like someone dictating my hair style.
On 28 Mar 2014, at 02:05, Daniel Micay danielmi...@gmail.com wrote:
On 27/03/14 04:42 PM, Tommi wrote:
A flag that removes safety is pretty antithical to the goals of the
language, IMHO.
Yes, I agree it's
danielmi...@gmail.com wrote:
On 27/03/14 09:02 PM, Tommi Tissari wrote:
Compiling with that flag would figuratively speaking wrap everything inside
an unsafe block and then omit vector bounds checking. The flag wouldn't be
allowed for library builds.
What I find a bit totalitarian about
is memory safe (although it's opt-in) and it has this
noboundscheck flag. So I don't see what the problem is.
On 28 Mar 2014, at 03:17, Daniel Micay danielmi...@gmail.com wrote:
On 27/03/14 09:02 PM, Tommi Tissari wrote:
the language forces a decision which the programmer should
On 28 Mar 2014, at 03:41, Jeffery Olson olson.jeff...@gmail.com wrote:
forces a decision which the programmer should be allowed to make for
himself. A bit like someone dictating my hair style.
Yes. Rust is just like hair salon that forbids you from setting your own hair
on fire.
rust have this flag too.
On 28 Mar 2014, at 04:26, Daniel Micay danielmi...@gmail.com wrote:
On 27/03/14 10:04 PM, Tommi Tissari wrote:
Opting in case by case is not the same thing as having a compiler flag which
you can toggle without modifying the source.
A case-by-case basis
I'm sorry for being kind of off-topic here, but whatever you decide on this
matter, I'd still like to be able to emulate multiple-inheritance using the
following idiom (which requires being able to say that a trait method is
private or, preferably, why don't we make trait methods private by
I think there's some unnecessary mental strain in having to think about whether
things are private or public by default. Every now and then it causes that
short pause where you need to go: Do I have to put 'pub' in front of this
thing? Oh, it's a trait implementation... do I don't or ...Oh,
On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin simon.sa...@exyr.org wrote:
Proposal:
0. An iterator is said to be well-behaved if, after its .next() method has
returned None once, any subsequent call also returns None.
I agree with the spirit of your proposal. But I would change that
On 04 Mar 2014, at 15:59, Simon Sapin simon.sa...@exyr.org wrote:
On 04/03/2014 13:23, Tommi wrote:
On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin simon.sa...@exyr.org
mailto:simon.sa...@exyr.org wrote:
Proposal:
0. An iterator is said to be well-behaved if, after its .next()
method has
The problem:
When you iterate over elements of an Iterator in a for-loop, you effectively
end up checking whether the Iterator is empty or not twice per element, i.e.
once inside the Iterator's next method and once in doing match for the Option
returned by the next method.
Example:
struct
On 04 Mar 2014, at 23:05, Daniel Micay danielmi...@gmail.com wrote:
On 04/03/14 03:51 PM, Tommi wrote:
The problem:
When you iterate over elements of an Iterator in a for-loop, you effectively
end up checking whether the Iterator is empty or not twice per element, i.e.
once inside
In the following example, I have a function which takes an input-iterator to
ints. It would be a loss of generality for that function to require its
iterator argument to return its elements by pointer, because generator
iterators like range(x, y) or random number generators etc. generally must
On 2013-11-22, at 7:42, Patrick Walton pcwal...@mozilla.com wrote:
I think it's unlikely that the performance hit there would be significant.
Actually, the example you gave, there won't be any at all because it'll be
devirtualized and inlined.
Oh, okay, that's good to hear.
There is
On 2013-11-20, at 18:27, Patrick Walton pcwal...@mozilla.com wrote:
On 11/19/13 9:42 PM, Tommi wrote:
Our problem is that, given let arg: ~A;, seeing only foo(arg) in code
doesn't tell us whether arg is moved or borrowed. The proposed solution
is that auto-borrowing in that context would
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
On 2013-11-21, at 4:16, Ziad Hatahet hata...@gmail.com wrote:
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
On 2013-11-20, at 1:40, Benjamin Striegel ben.strie...@gmail.com wrote:
If autoref still happens on methods, does this mean that you'd be able to get
around the need to do:
sort(mut *foo);
...by turning it into a method?
foo.sort();
I like how your argument nudges this whole
On 2013-11-20, at 6:24, Patrick Walton pcwal...@mozilla.com wrote:
On 11/19/13 7:43 PM, Tommi wrote:
I like how your argument nudges this whole discussion a few inches to
the left. Now we see that disallowing auto-borrowing from regular
function arguments doesn't buy us anything unless we
On 2013-11-20, at 7:13, Tommi rusty.ga...@icloud.com wrote:
Yeah, my claim that it doesn't buy us anything stemmed from a misconception
that arg.foo() could move arg, given let arg: ~A; and fn foo(x: ~A) {...}. I
had already forgotten that Rust UFCS was specified differently from D's
On 2013-11-16, at 1:37, Tommi Tissari rusty.ga...@icloud.com wrote:
But shouldn't the signature be:
fn cmpT(x: [T], y: [T]) - bool
Oh, wait I think I know what the answer to that question is going to be. The
comparison trait requires the signature to be (self, Self) and since the
pointer
1 - 100 of 114 matches
Mail list logo
