On 21 June 2014 22:03, Igor Bukanov wrote:
> On 20 June 2014 21:07, Paulo Sérgio Almeida wrote:
> > I have seen many other examples, where the code could mislead the reader
> into
> > thinking there are several, e.g., Mutexes:
> >
> > let mutex = Arc::new(
compiler. There's little point in having a
> powerful and extensible language if even simple types need hardcoded
> compiler magic to function.
>
>
> On Sat, Jun 21, 2014 at 7:42 AM, Paulo Sérgio Almeida <
> pssalme...@gmail.com> wrote:
>
>> Regarding the wh
gt;>> this, I would rather go back to having @-pointers). The trouble is, I see
>>> incrementing a ref count as the upper bound on the work that should be done
>>> in a copy constructor and I see no way to enforce that.
>>>
>>> So, I guess +1 to spirit of t
Regarding the white-listing, I also find it weird, but should the user
experience be worse just because Rc and Arc are implemented in Rust and so
we should do nothing in the name of orthogonality? A user won't care if Arc
and Rc are built-in or not.
I may have passed the message that its only ugli
Hi all,
Currently being Copy equates with being Pod. The more time passes and the
more code examples I see, it is amazing the amount of ugliness that it
causes. I wonder if there is a way out.
There are two aspects regarding Copy: the semantic side and the
implementation side. On the more abstrac
Nice!
On 24 May 2014 12:42, Huon Wilson wrote:
> I believe much of the underlying issue is covered by #12808. I have just
> filed a pull request #14402 to "fix" the immediate symptoms of this bug by
> making it harder to accidentally have struct fields taht conflict with the
> private fields o
you filed an issue on the
> GitHub issues page? https://github.com/mozilla/rust/issues/new
>
> -Kevin
>
> On May 23, 2014, at 6:04 AM, Paulo Sérgio Almeida
> wrote:
>
> Hi all, (resending from different email address; there seems to be a
> problem with my other add
Hi all, (resending from different email address; there seems to be a
problem with my other address)
I don't know if this has been discussed, but I noticed an unpleasant
interaction between private fields in the implementation of things like
pointer types and auto-dereferencing.
The example I
} else {
None
}
}
could be written as:
fn next(iter: &Iterator) -> Option<&T> {
iter.index += 1;
if iter.index < iter.source.len() {
Some(&iter.source[iter.index])
} else {
None
particularly true for "non-library" code, and even more true with
judicious use of `@` pointers (it is often not worth the trouble to
avoid the GC; it can make life much easier, that's what it's there for).
So in summary I do not think it likely we will change the curren
On 4/22/13 5:48 PM, Diggory Hardy wrote:
Please don't use HTML when posting to lists.
Sorry. I hope this one goes in plain text. (Added a text domain to
Thunderbird.)
2) function parameter types or return type that are not type parameters have
all the same implicit lifetime by default, but they
Hi all,
(My first post here.)
First, congrats for what you are trying to achieve with Rust. I arrived
very late to the party, and so I am not sure that what I will say can be
of use. But as I understand, lifetimes is one of those things that are
not completely solidified, and anyway, better la
12 matches
Mail list logo
