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 2014-06-1
been 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 wrote:
> On 6/12/14 11:15 AM, Tommi wrote:
>> On 2014-06-12, at 20:59, Corey Richardson > <mailto
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 st
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 21:10, Isaac Dupree 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 compile
I realized that, in my proposal, there's a potentially pretty confusing
asymmetry of what `stable` means. In the trait definition:
pub trait Mul {
fn mul(stable self, rhs: &RHS) -> Result;
}
...the keyword `stable` means that however the type which implements this trait
decides to pass `sel
On 2014-06-15, at 9:56, Benjamin Striegel 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 that: "this function arg
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
On 2014-06-13, at 13:14, Tommi wrote:
> pub trait Mul {
> 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 Mul {
f
That was assuming `Vector` implements `Clone`. For example:
#[deriving(Clone)]
struct Vector {
coordinates: Vec
}
On 2014-06-13, at 13:14, Tommi wrote:
> Taking an argument by "stable value" (as `self` above) means that any
> (clonable) variable passed in as that argume
The problem:
Chained calls to certain operators such as binary `*` and `+` may cause
unnecessary memory allocations. For example:
struct Vector {
coordinates: Vec
}
impl Mul for Vector {
fn mul(&self, rhs: &int) -> Vector {
let mut new_coordinates = self.coordinates.clone();
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 t
On 2014-06-12, at 21:15, Patrick Walton wrote:
> On 6/12/14 11:15 AM, Tommi wrote:
>> On 2014-06-12, at 20:59, Corey Richardson > <mailto:co...@octayn.net>> wrote:
>>
>>> Implicit cloning is a non-starter. Clones can be very expensive.
>>> Hidi
On 2014-06-12, at 20:59, Corey Richardson 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 error of writi
On 2014-06-12, at 20:51, Patrick Walton 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 fun
.
>
> On Thu, Jun 12, 2014 at 10:26 AM, Tommi 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:
&
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 2014-06-12, at 19:08, Patrick Walton 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 something like t
On 2014-06-12, at 19:05, Patrick Walton wrote:
> On 6/12/14 1:02 AM, Tommi wrote:
>> On 2014-06-11, at 16:27, SiegeLord > <mailto:slab...@aim.com>> wrote:
>>
>>> So, I think the situation is pretty bad. What can be done to fix it?
>>
>> I agree
On 2014-06-11, at 16:27, SiegeLord 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-11, at 21:47, Tommi 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 it
On 2014-06-11, at 21:33, Daniel Micay 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
said `Mul` and simila
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
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 wrote:
> +1, I was planning on suggesting this as well.
>
> On Jun 3, 2014 2:16 AM, "Tommi" wrote:
> I find it somewhat jarring to have to s
Apparently this works as well:
let t = Testnew().test();
println!("t={}", t);
On 2014-06-04, at 10:50, Tommi wrote:
> I don't know if there's a better way, but this at least works:
>
> let tmp: Test = Test::new();
> let t = tmp.test();
> println!("
I don't know if there's a better way, but this at least works:
let tmp: Test = Test::new();
let t = tmp.test();
println!("t={}", t);
On 2014-06-04, at 10:28, Igor Bukanov wrote:
> What is the syntax for calling a static method of a generic struct
> while selecting the the generic parameters exp
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 `self
On 2014-06-02, at 10:44, Tommi 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, aliased mutat
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 pla
On 2014-06-01, at 13:48, Gábor Lehel 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 inherent incompl
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 proble
On 2014-06-01, at 2:45, Huon Wilson 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-06-01, at 1:02, Patrick Walton wrote:
>fn my_transmute(value: T, other: U) -> U {
>let mut x = Left(other);
>let y = match x {
>Left(ref mut y) => y,
>Right(_) => fail!()
>};
>*x = Right(value);
>(*y).clone()
>}
If `
On 2014-05-31, at 20:44, Patrick Walton 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.
On 2014-05-31, at 22:13, Matthieu Monrocq wrote:
> Another example of memory issue:
>
> foo(left: &Option>, right: &mut Option>) {
> let ptr: &str = *left.unwrap();
>
> right = None;
>
> match ptr.len() { // Watch out! if left and right alias, then ptr is
> no a da
It certainly feels like a failure of the Rust type system that you cannot have
multiple mutating references to the same variable when the variable is accessed
only from a single thread. I know the reason for this is to prevent iterator
invalidation, but this is too blunt of an instrument.
Itera
Disclaimer:
I understand that Rust used to use internal iteration in for-loops, but that
was before I became interested in this language, so my perspective on this
matter may not match yours.
I suppose internal iteration support in for-loops should be preferably
implemented through the use of r
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 4:16, Eric Reed 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 saying that the compiler
On 2014-05-30, at 3:28, comex wrote:
> On Thu, May 29, 2014 at 8:21 PM, Tommi 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, then the program
On 2014-05-30, at 3:42, Eric Reed 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 figure out how exactly to d
On 2014-05-30, at 2:48, comex wrote:
> On Thu, May 29, 2014 at 7:01 PM, Tommi 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 the optimiz
Function overloading is a language feature that is necessary in order to
prevent implementation details from becoming a part of an interface.
Example:
// Assuming function overloading exists...
trait A {
// Basic functionality:
...
}
trait B : A {
// Extended functionality:
...
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(Box) }
let shape = Sphere(box 1.0f32);
let r = match shape {
Sphere(box ref radius) => *radius
};
I thought the 'box' keyword
the box.
>
>
>> On Tue, May 27, 2014 at 10:27 AM, Tommi 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 post
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:
enum Shape { Sphere(Box) }
let shape = Sphere(box 1.0f3
memory.
> On 27 May 2014, at 19:50, Kevin Ballard wrote:
>
> What's the use-case for this?
>
> -Kevin
>
>> On May 27, 2014, at 3:24 AM, Tommi wrote:
>>
>> Could we add to the standard library a macro, say 'include_sized_bin', that
>&g
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 si
On 2014-05-17, at 3:54, Kevin Ballard wrote:
> On May 15, 2014, at 9:54 PM, Daniel Micay wrote:
>
>> On 16/05/14 12:48 AM, Tommi wrote:
>>> On 2014-05-16, at 7:35, Steven Fackler wrote:
>>>
>>>> Type annotations are not there for the compiler; they&
On 2014-05-16, at 7:35, Steven Fackler wrote:
> Type annotations are not there for the compiler; they're there for people
> reading the code. If I want to use some function I don't want to be forced to
> read the entire implementation to figure out what the lifetime of the return
> value is.
On 2014-05-16, at 7:14, Daniel Micay 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
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
Rust-dev@mozilla
On 2014-04-22, at 21:44, Brian Anderson 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 to do that, if I kn
the guide [1]
For completeness sake, here's the first fork (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:
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 wrote:
> Could someone please commit this RFC
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. d
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 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:
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 su
On 2014-04-17, at 11:25, Marvin Löbel 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 macro producing boiler
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 typ
On 2014-04-16, at 4:39, Brandon Sanderson 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
> 'bugprone' keyword
On 2014-04-16, at 4:34, Daniel Micay 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
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 in release builds. I'll also assume that there will be a
macro called 'enforce' that will do the same thin
All the reasoning above applies 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 wrote:
.
> On 10 Apr 2014, at 09:27, Kevin Ballard wrote:
>
> On Apr 9, 2014, at 11:25 PM, Tommi Tissari wrote:
>
>>> On 10 Apr 2014, at 07:55, Corey Richardson wrote:
>>>
>>> range doesn't return a forward iterator. Range also implements
>>> Doubl
> On 10 Apr 2014, at 07:55, Corey Richardson wrote:
>
> range doesn't return a forward iterator. Range also implements
> DoubleEndedIterator.
Ok, I didn't realize that. But it still should't require Add when all it
needs is a way to get to the next and previous values.
___
> On 10 Apr 2014, at 07:53, Kevin Ballard wrote:
>
> On Apr 9, 2014, at 9:50 PM, Tommi Tissari wrote:
>
>>> On 10 Apr 2014, at 00:22, Kevin Ballard wrote:
>>>
>>> FWIW, my point about range is it relies on One being the number 1, rather
>>&g
> On 10 Apr 2014, at 00:22, Kevin Ballard 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
> not co
> On 09 Apr 2014, at 23:42, Kevin Ballard wrote:
>
> The number 0 is the additive identity for numbers. But informally, the
> additive identity for other things can be called "zero" without problem.
Ok, so it seems. From
http://en.m.wikipedia.org/wiki/Identity_(mathematics)
The number 0 is the
> On 09 Apr 2014, at 20:46, Kevin Ballard 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 RandomAcc
> On 09 Apr 2014, at 20:46, Kevin Ballard 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 neither num
s,
>
> Rémi
>
>
>
>> On Wed, Apr 9, 2014 at 5:20 AM, Kevin Ballard wrote:
>>> On Apr 7, 2014, at 1:02 AM, Tommi Tissari wrote:
>>>
>>>> On 07 Apr 2014, at 08:44, Nicholas Radford
>>>> wrote:
>>>>
>>>> I t
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 prote
question. What does saying 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&q
On 2014-04-04, at 12:30, Vadim Chugunov 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 for defining
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 Add, you must implement it (the
supertrait) also.
On 2014-06-04, at 11:2
> On 04 Apr 2014, at 12:30, Vadim Chugunov 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
> would hap
:37, Corey Richardson 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 wrote:
>> I forgot to mention that this same space-optimization
I forgot to mention that this same space-optimization could be done for
Option already.
On 2014-04-04, at 03:18, Tommi 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 exact
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 (un
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 15:43, Matthew Frazier 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.
__
On 28 Mar 2014, at 14:47, Daniel Micay 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 rang
On 28 Mar 2014, at 17:46, Erick Tryzelaar 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 always good and that it's goo
On 28 Mar 2014, at 15:01, Huon Wilson 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 isn't the langua
On 28 Mar 2014, at 14:27, Daniel Micay wrote:
> On 28/03/14 08:25 AM, Tommi wrote:
>> On 28 Mar 2014, at 05:56, Patrick Walton wrote:
>>>
>>> I think that Rust should give you the ability to opt out of safety, but on
>>> a per-operation basis. Having it a
On 28 Mar 2014, at 05:56, Patrick Walton 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
> checked in the nam
On 28 Mar 2014, at 05:48, Daniel Micay 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 boundaries
> complet
And I was wondering
why can't rust have this flag too.
> On 28 Mar 2014, at 04:26, Daniel Micay 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 mo
On 28 Mar 2014, at 03:41, Jeffery Olson 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.
>
>
> Yes. Rust is jus
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 wrote:
>
>> On 27/03/14 09:02 PM, Tommi Tissari wrote:
>>
>> the language forces a decision which the progra
y 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.
>>
>>
ammer should be allowed to make for himself. A bit
like someone dictating my hair style.
> On 28 Mar 2014, at 02:05, Daniel Micay wrote:
>
>> On 27/03/14 04:42 PM, Tommi wrote:
>>
>>> A flag that removes safety is pretty antithical to the goals of the
>>> lan
On 27 Mar 2014, at 22:17, Steve Klabnik 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
>> checking in
[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?
Wh
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 defa
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, i
On 04 Mar 2014, at 23:05, Daniel Micay 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.
&g
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 15:59, Simon Sapin wrote:
> On 04/03/2014 13:23, Tommi wrote:
>> On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin > <mailto:simon.sa...@exyr.org>> wrote:
>>
>>> Proposal:
>>>
>>> 0. An iterator is said to be "well-beha
1 - 100 of 128 matches
Mail list logo
