incremental, in the
direction of a more engaged and collaborative process, as opposed to just
an ultimate accept/postpone/reject decision, would be very much appreciated.
Cheers
Cheers, Nick
On Mon, Jul 14, 2014 at 2:29 AM, Gábor Lehel glaebho...@gmail.com wrote:
On Fri, Jul 11, 2014 at 2:48 AM
Hello list,
There are a couple of subjects I've been trying to ask for information
about in comments here-and-there, and by and large not succeeding very
much, so I thought I would try again, this time to a whole mailing list. (I
was thinking of just asking on IRC, but perhaps an email
On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron li...@ncameron.org wrote:
https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce
universal quantification - glaebhoerl
Use `for` rather than `...` syntax for type-parametric items.
Not much feedback, some discussion.
On Wed, Jul 2, 2014 at 8:56 PM, Brian Anderson bander...@mozilla.com
wrote:
On 07/02/2014 11:19 AM, Gábor Lehel wrote:
Thanks, this is a good step, as is delaying taking actions by a day
as proposed in the meeting itself.
If you have any suggestions for how this regular email
On Wed, Jul 2, 2014 at 11:05 PM, Nick Cameron li...@ncameron.org wrote:
On Thu, Jul 3, 2014 at 6:19 AM, Gábor Lehel glaebho...@gmail.com wrote:
Thanks, this is a good step, as is delaying taking actions by a day as
proposed in the meeting itself.
If you have any suggestions for how
Thanks, this is a good step, as is delaying taking actions by a day as
proposed in the meeting itself.
If you have any suggestions for how this regular email or the process in
general could be improved, please let us know.
Most fundamentally, what I'm wondering is, why do most of the things
Thanks to everyone for the excellent feedback. I've submitted an RFC
incorporating many of the ideas from the discussion:
https://github.com/rust-lang/rfcs/pull/146
On Fri, Jun 27, 2014 at 5:58 PM, Patrick Walton pcwal...@mozilla.com
wrote:
On 6/27/14 1:31 AM, Igor Bukanov wrote:
This bug
On Sat, Jun 21, 2014 at 3:31 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 5:36 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Sat, Jun 21, 2014 at 1:37 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel glaebho...@gmail.com
On Sat, Jun 21, 2014 at 11:21 PM, Vadim Chugunov vadi...@gmail.com wrote:
My 2c:
The world is finally becoming security-conscious, so I think it is a only
matter of time before architectures that implement zero-cost integer
overflow checking appear. I think we should be ready for it when
On Sun, Jun 22, 2014 at 2:02 AM, Daniel Micay danielmi...@gmail.com wrote:
On 21/06/14 07:55 PM, Benjamin Striegel wrote:
No one will use Rust if it's slow. If it uses checked arithmetic, it
will be slow. There's nothing subjective about that.
This is the only argument that matters.
On Sun, Jun 22, 2014 at 11:05 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 22/06/14 09:31 AM, Gábor Lehel wrote:
The prospect of future architectures with cheaper (free) overflow
checking isn't my primary motivation, though if we also end up better
prepared for them as a side effect
On Wed, Jun 18, 2014 at 8:20 PM, Daniel Micay danielmi...@gmail.com wrote:
On 18/06/14 01:08 PM, Gábor Lehel wrote:
# Exposition
We've debated the subject of integer overflow quite a bit, without much
apparent progress. Essentially, we've been running in circles around two
core facts
On Wed, Jun 18, 2014 at 10:05 PM, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Wed, Jun 18, 2014 at 10:08 AM, Gábor Lehel glaebho...@gmail.com
wrote:
memory safety bugs.) This is a step up from C's insanity of undefined
behavior for signed overflow, where the compiler assumes that overflow
On Wed, Jun 18, 2014 at 10:19 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 18/06/14 03:40 PM, comex wrote:
On Wed, Jun 18, 2014 at 1:08 PM, Gábor Lehel glaebho...@gmail.com
wrote:
To partially address this, once we have tracing GC, and if we manage to
make
`GcT: Copy`, we should add
, and the same thing might make sense for Rust.
On Wed, Jun 18, 2014 at 11:21 AM, Brian Anderson bander...@mozilla.com
wrote:
On 06/18/2014 10:08 AM, Gábor Lehel wrote:
# Checked math
For (2), the standard library offers checked math in the `CheckedAdd`,
`CheckedMul` etc. traits, as well
On Sat, Jun 21, 2014 at 1:37 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Thu, Jun 19, 2014 at 9:05 AM, Jerry Morrison jhm...@gmail.com wrote:
Nice analysis!
Over what scope should programmers pick between
# Exposition
We've debated the subject of integer overflow quite a bit, without much
apparent progress. Essentially, we've been running in circles around two
core facts: wrapping is bad, but checking is slow. The current consensus
seems to be to, albeit grudgingly, stick with the status quo.
I
alternative actions
for this scenario).
Did the above help answer your questions? Let me know if I missed the
point of one or more of your questions.
Cheers,
-Felix
On 16 Jun 2014, at 14:44, Gábor Lehel glaebho...@gmail.com wrote:
Hi!
There's a few things about the RFC process
Hi!
There's a few things about the RFC process and the meaning of RFCs which
aren't totally clear to me, and which I'd like to request some
clarification about.
1) Which of the following does submitting an RFC imply?
1a) We should implement this right away.
1b) We should implement this before
Well, not possible in the general case, to be more precise. 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
Disallow taking the address of a non-mut static value unless it is Freeze
Can someone explain why this is necessary?
static FOO: OptionCellint = None;
let foo = FOO;
Why would this be a problem? Or is this not what's being referred to?
Actually... given that you can't move out of a
On Fri, Mar 14, 2014 at 8:32 PM, Alex Crichton a...@crichton.co wrote:
Can someone explain why this is necessary?
static FOO: OptionCellint = None;
let foo = FOO;
Implementation-wise, FOO is placed into read-only memory in the
executable. This is done mainly for optimization
On Fri, Mar 14, 2014 at 9:35 PM, Alex Crichton a...@crichton.co wrote:
I was working from the assumption that the initializers of non-mut
statics
are checked to ensure they do not contain values of non-Freeze types, nor
destructors. Does the new plan also involve lifting this restriction?
See also https://github.com/mozilla/rust/issues/8122
On Thu, Mar 6, 2014 at 1:11 PM, Tommi rusty.ga...@icloud.com wrote:
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
On Sat, Mar 1, 2014 at 9:07 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Fri, Feb 28, 2014 at 11:23:23PM -0800, 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
On Sat, Mar 1, 2014 at 8:24 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Fri, Feb 28, 2014 at 10:36:11PM +0100, Gábor Lehel wrote:
I don't see the difference here. Why do you think this should be handled
differently?
To be honest I hadn't thought about it before. I agree
Me three. I thought the last of this reading-while-mut was excised with
the removal of @mut.
If you think you might like to implement this change, though, let me
know. =)
Given generous amounts of hand-holding, I might give it a shot.
On Tue, Feb 25, 2014 at 10:23 PM, Kevin Ballard
On Fri, Feb 14, 2014 at 12:35 AM, Daniel Micay danielmi...@gmail.comwrote:
On Thu, Feb 13, 2014 at 6:33 PM, Erick Tryzelaar
erick.tryzel...@gmail.com wrote:
On Thursday, February 13, 2014, Gábor Lehel glaebho...@gmail.com
wrote:
This is not strictly true.
If instead of
fn
On Thu, Feb 13, 2014 at 5:09 PM, Olivier Renaud o.ren...@gmx.fr wrote:
As you said, the type system can not enforce this rule, that's why
the documentation have no choice but to say the behavior is undefined.
This is not strictly true.
If instead of
fn next(mut self) - OptionA;
we had
Just because Any is a trait doesn't mean it doesn't break parametricity.
Look at this:
http://static.rust-lang.org/doc/master/src/std/home/rustbuild/src/rust-buildbot/slave/doc/build/src/libstd/any.rs.html#37-63
Because we have `implT: 'static Any for T`, it can be used with *any
type* (except
, Gábor Lehel glaebho...@gmail.com wrote:
On Mon, Feb 3, 2014 at 7:55 AM, Corey Richardson co...@octayn.netwrote:
Default typarams are awesome, but they're gated, and there's some
concern that they'll interact unpleasantly with extensions to the type
system (most specifically, I've seen concern
, but if even a little information is
provided, well feel free to do whatever you like.
I had the same thought about making size_of and friends unsafe functions.
I think that might be a reasonable idea.
On Mon, Feb 3, 2014 at 5:35 AM, Gábor Lehel glaebho...@gmail.com wrote:
Just because Any
On Mon, Feb 3, 2014 at 7:55 AM, Corey Richardson co...@octayn.net wrote:
Default typarams are awesome, but they're gated, and there's some
concern that they'll interact unpleasantly with extensions to the type
system (most specifically, I've seen concern raised around HKT, where
there is
On Mon, Jan 27, 2014 at 12:03 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Sat, Jan 25, 2014 at 07:07:32PM +0100, Gábor Lehel wrote:
If you wanted to pass an unboxed closure without indirection though, like
`fn fooT: FnU, R(x: T)`, then you would have to explicitly
dereference
On Sun, Jan 26, 2014 at 1:26 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Sun, Jan 26, 2014 at 3:31 AM, Brian Anderson bander...@mozilla.comwrote:
On 01/25/2014 08:58 AM, Bill Myers wrote:
Stack management for green tasks has been based in the past first on
segmented stacks
On Sat, Jan 25, 2014 at 9:26 PM, Vadim vadi...@gmail.com wrote:
Hi Bill,
If I understand this right, what you are proposing is the approach of
Python's greenlets library, which I already tried to pitch
herehttp://mail.mozilla.org/pipermail/rust-dev/2013-November/006544.html.
I think that
On Sun, Jan 26, 2014 at 2:02 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Sat, Jan 25, 2014 at 9:26 PM, Vadim vadi...@gmail.com wrote:
Hi Bill,
If I understand this right, what you are proposing is the approach of
Python's greenlets library, which I already tried to pitch
herehttp
-looking APIs. The alternative, I guess, is to block 1.0 on unboxed
closures, convert all our APIs to unboxed closures where possible, and just
say that if you want a boxed closure you have to write `mut |x| x + 1` at
each closure construction site...
Patrick
Gábor Lehel glaebho
Would it be accurate to say that the only significant changes required at
the language level for all this would be not having a default integer type,
and then probably polymorphic number literals a la Haskell? And that the
rest of this discussion is only about policy and ergonomics?
On Mon, Jan
On Sat, Jan 11, 2014 at 11:18 AM, Marijn Haverbeke mari...@gmail.comwrote:
I am not aware of an efficient way to provide
automatic-overflow-to-bignum semantics in a non-garbage-collected
language, without also imposing the burden of references/move
semantics/etc on users of small integers.
On Fri, Jan 10, 2014 at 8:01 PM, Daniel Micay danielmi...@gmail.com wrote:
On Fri, Jan 10, 2014 at 1:57 PM, Patrick Walton pwal...@mozilla.com
wrote:
It doesn't exist, outside of traits. Unboxed closures will probably make
it
possible to express once again though.
Patrick
The tricky
The other day on IRC `mitsuhiko` (who I believe is actually Armin, the OP
in this thread) wrote that he would like to be able to write something like
fn my_pipelineI: IteratorT(x: I) - IteratorT { ... }
and that got stuck in my head: maybe it's not such a crazy idea. The
objections to having
On Tue, Dec 31, 2013 at 4:41 PM, Daniel Micay danielmi...@gmail.com wrote:
On Tue, Dec 31, 2013 at 10:39 AM, Gábor Lehel glaebho...@gmail.com
wrote:
Speaking of which: I completely agree with Patrick that there's no point
to
blocking Rust 1.0 on backwards compatible features. The reason
It would be helpful to know what the (rough) plan is for after 1.0. A
series of 1.x releases and later 2.0, or just 2.0? At what kind of time
scales? What kind of changes will be appropriate for each? (i.e. language
features, bugfixes, compatibility breaks of various forms in various places)
How
Wouldn't it have to be `mut` rather than `` to fit the semantics of | |,
which is affine and can mutate its environment?
And wouldn't this lead to divergence between the type- and value syntax,
with | | as a type being a boxed closure (`mut FnMut`), and an unboxed
closure as a value? This was one
.
--
Ziad
On Sun, Dec 22, 2013 at 10:37 AM, Léo Testard leo.test...@gmail.com
wrote:
Hello,
Le 22 déc. 2013 à 18:59, Stefan Plantikow stefan.planti...@gmail.com
a
écrit :
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel glaebho...@gmail.com:
This is a nice idea
On Sun, Dec 22, 2013 at 7:37 PM, Léo Testard leo.test...@gmail.com wrote:
Hello,
Le 22 déc. 2013 à 18:59, Stefan Plantikow stefan.planti...@gmail.com a
écrit :
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel glaebho...@gmail.com:
This is a nice idea. At first I thought it wouldn’t
, Dec 23, 2013 at 12:23 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/23/13 4:12 AM, Gábor Lehel wrote:
I don't like either that (a) the possible failure is silent, and
refutable lets look the same as irrefutable ones, nor (b) baking fail!()
into the semantics. Haskell has these also and I
Using `match` works well enough, but if there's demand for a refutable
`let` which is lighter-weight, what about:
let Some(result) = from_utf8(some_bytes) else fail!();
In other words, if the `let` pattern is refutable, you have to provide
something `else` with return type `!` as the
I don't have any special expertise in or experience with this, I'm just
trying to draw logical inferences from what others have written.
Stated:
- From a semantic perspective the only distinction is between bounded and
unbounded queues. The capacity of a bounded queue only makes a difference
On Sun, Dec 8, 2013 at 10:26 AM, Ziad Hatahet hata...@gmail.com wrote:
On Sat, Dec 7, 2013 at 2:21 PM, Gábor Lehel illiss...@gmail.com wrote:
I do wonder whether it wouldn't make sense to add sugar for Option, at
least eventually. (`int?` at the type level is really nice, too... too bad
Short version: yes, higher-kinded types and template template parameters
are the same thing. (`templatetypename class` is just one particular
higher kind; there's also `templatetemplatetypename class class` and so
on, and varying the number of parameters, etc., which you probably know.)
Longer
, and if we were to
add HKT, there would be no reason to restrict them to only being associated
types.
On Sat, Dec 7, 2013 at 9:05 PM, Gábor Lehel illiss...@gmail.com wrote:
Short version: yes, higher-kinded types and template template parameters
are the same thing. (`templatetypename class` is just
I agree with this proposal. I also strongly agree with spir that we should
distinguish programmer errors from legitimate result possibilities. A
function should only fail directly if, were it to return a `None` or `Err`,
the only reasonable the thing caller could do would be to fail itself.
In a similar vein, see this list of complaints against Scala by Edward
Kmett, possibly the most brilliant and prolific Haskell programmer on Earth:
http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu
I'll try to comment with my understanding
On Thu, Dec 5, 2013 at 5:07 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Dec 5, 2013 at 10:43 AM, Gábor Lehel illiss...@gmail.com wrote:
The container types they do have have weird ad hoc overloadings. e.g. Map
is treated as an iterable container of pairs, but this means you can't
think
we would end up wanting the sugar.
Patrick
Gábor Lehel illiss...@gmail.com wrote:
Yes, that was one of the things that passed through my mind as well. One
difference is that those are passed at runtime, whereas here everything
happens at compile time. I remember LLVM had difficulty
On Mon, Dec 2, 2013 at 7:18 PM, Niko Matsakis n...@alum.mit.edu wrote:
OK, I read a bit more. I've been working on a blog post about HKR
(higher-kinded Rust) and you've been elaborating on some of the same
themes as I was thinking about (naturally enough). All makes sense.
...which was part
Yes, that was one of the things that passed through my mind as well. One
difference is that those are passed at runtime, whereas here everything
happens at compile time. I remember LLVM had difficulty reliably optimizing
runtime closure passing code, like with the old iterators.
On Wed, Dec 4,
On Sat, Nov 30, 2013 at 10:17 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/30/13 1:01 AM, Kevin Ballard wrote:
As
for placement new, while it needs to be supported in some fashion, it's
going to be used pretty rarely, such that I don't think it's worth
reserving a keyword just for
On Sat, Nov 30, 2013 at 11:35 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
The other suggestion that's been floated that satisfies all of these
constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
should just switch to that.
I much prefer `new` to `alloc`. It *is*
On Wed, Nov 20, 2013 at 7:37 PM, Brian Anderson bander...@mozilla.comwrote:
On 11/20/2013 09:14 AM, Niko Matsakis wrote:
On Tue, Nov 19, 2013 at 07:19:15AM -0800, Patrick Walton wrote:
The liveness analysis uses the infinite nature of `loop`, and it was
felt that special-casing the `true`
Hmm? I think you think I meant that `loop` should accept a condition in
front of the loop, like `while`? In fact my idea was sillier: just replace
all instances of `while foo { bar }` with
loop {
if !foo { break }
bar
}
On Wed, Nov 20, 2013 at 9:56 PM, Benjamin Striegel
On Sun, Nov 17, 2013 at 2:08 AM, Niko Matsakis n...@alum.mit.edu wrote:
On Fri, Nov 15, 2013 at 05:05:28PM +0100, Gábor Lehel wrote:
I have some ideas about typey things and I'm going to write them down. It
will be long.
I haven't read this all yet, I just want to respond to the first few
In case this helps, I recently noticed that the sigils correspond to
possessive pronouns:
'~' = my,
'' = their,
'@' = our
Of course, `@` might be going away, but `Rc`, `Gc`, and so forth all
(will) have the same intuitive content, only different representations
(among other
On Sat, Nov 16, 2013 at 1:07 AM, Huon Wilson dbau...@gmail.com wrote:
On 16/11/13 03:05, Gábor Lehel wrote:
It would be nice if `Trait1 + Trait2` were itself a trait, legal in the
same positions as any trait. This is already partly true: in trait bounds
on type parameters and super-traits
On Sat, Nov 16, 2013 at 12:30 PM, Gábor Lehel illiss...@gmail.com wrote:
What I was wondering in the parentheses above is whether you could have
something `typetype MTtypetype`. In other words whether templates
can return templates, which you can't do in C++ but can in Haskell
Does anyone have empirical data (or even anecdotes) about whether or not
C++ hackers find Rust's syntax appealing? :-)
On Tue, Nov 12, 2013 at 10:53 AM, spir denis.s...@gmail.com wrote:
On 11/11/2013 09:46 PM, Corey Richardson wrote:
I don't think Rust can succeed as a language if it
On Sat, Nov 9, 2013 at 7:43 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
Many thanks for the replies.
My problem is actually in accessing private methods/members of a struct
defined in a different, but very closely related module. It seems @
nikomatsakis https://github.com/nikomatsakis is
On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton pwal...@mozilla.comwrote:
I think it's unfortunately too late to overhaul the language like this.
This will require redesigns of all Rust code in existence.
I do like unified function/method call syntax, but I think it can be done
in a
On Sun, Oct 20, 2013 at 4:56 PM, Patrick Walton pwal...@mozilla.com wrote:
I don't see the things you mention as warts. They're just consequences of,
well, having methods in the OO sense. Nearly all of these warts show up
in other object-oriented languages too. Maybe they're warts of
On Sun, Oct 20, 2013 at 5:11 PM, Marijn Haverbeke mari...@gmail.com wrote:
Another problem with this proposal seems that it does away with the
possibility of explicitly grouping a bunch of methods that make up the
implementation of an interface. Implementing interfaces go-style, by
just
On Sun, Oct 20, 2013 at 7:31 PM, Gábor Lehel illiss...@gmail.com wrote:
So I very much agree with Patrick. Some aspects of this proposal are
attractive, but it breaks some essential properties of the way methods
currently work (and probably can't be adjusted to work around that
without losing
On Sun, Oct 20, 2013 at 8:01 PM, Patrick Walton pwal...@mozilla.com wrote:
What would happen if two types defined a method called, say, foo, and
the importing module glob imported them both?
Here's the part where I have to say that I'm not intimately familiar with
how Rust's existing method
On Sun, Oct 20, 2013 at 7:31 PM, Gábor Lehel illiss...@gmail.com wrote:
On Sun, Oct 20, 2013 at 5:11 PM, Marijn Haverbeke mari...@gmail.comwrote:
Another problem with this proposal seems that it does away with the
possibility of explicitly grouping a bunch of methods that make up
On Sun, Oct 20, 2013 at 8:16 PM, Patrick Walton pwal...@mozilla.com wrote:
But then it seems strange to require that the methods be imported at all,
if you're going to do single-dispatch type-based resolution on them anyway.
Well, it would do type-based resolution based on the methods which
On Sun, Oct 20, 2013 at 9:38 PM, Patrick Walton pwal...@mozilla.com wrote:
I guess I just don't see the value in requiring imports of names when
there can be no ambiguity and they're defined in one place (the impl of the
type, defined in the same place as the type itself). One person's magic
On Sat, Oct 19, 2013 at 4:08 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I'm less certain about giving up `impl Foo { ... }`, though - that is
useful for logically grouping, documenting and accessing functions (as in
`Foo::foo(...)`). But it seems we don't have to give it up, just make it
On Fri, Oct 18, 2013 at 6:09 PM, Jack Moffitt j...@metajack.im wrote:
If we decide that both API styles are good to have, what should the
naming convention be for the functional vs. mutable ones? Ruby,
Scheme, and Clojure use `!` to denote the in-place mutation ones, but
that syntax is for
On Mon, Sep 30, 2013 at 8:31 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
Huh, this is _exactly_ my use case. I have data structures which I grow
but never shrink, and I never move anything out of them. This idiom isn't
that uncommon when writing in functional style...
I incrementally build a
'self is not special in any way, except that the compiler has historical
baggage such that 'self is the only name it lets you use for a lifetime
parameter on a struct. But that's a bug. In the ideal platonic Rust in the
sky, you can have any number of lifetime parameters on a struct with
whatever
, Sep 29, 2013 at 8:24 PM, Gábor Lehel illiss...@gmail.com wrote:
'self is not special in any way, except that the compiler has historical
baggage such that 'self is the only name it lets you use for a lifetime
parameter on a struct. But that's a bug. In the ideal platonic Rust in the
sky, you can
I think I prefer .NET style. I liked the mixed approach, until I saw
it applied to GC/GcMut and co. I'm ambivalent about grandfathering in
IO: consistency is good, but Io /really does/ look unusually stupid,
with other acronyms it's not as ingrained for whatever reason. (I
wonder whether it has
I agree that overloadable * would be very desirable for smart
pointers. I also really like the interaction with newtypes. Is it
still the plan (from the GC thread) to push all mutability into Cell?
Would that interact with this proposal in any way (e.g. to allow
mutating through * in some cases)?
On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson bander...@mozilla.com wrote:
FWIW I prefer the terms box and reference. I don't really understand the
idea that only * is 'semantically a pointer' though.
Unique boxes
might
be worthwhile (like we already do for enums).
On Mon, Jul 29, 2013 at 4:47 PM, Gábor Lehel illiss...@gmail.com wrote:
On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay danielmi...@gmail.com
wrote:
On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson bander...@mozilla.com
wrote:
FWIW I
, with representations depending on whether T
is Sized?)
-Erick
On Saturday, July 27, 2013, Gábor Lehel wrote:
Some discussion has sprouted on reddit:
http://www.reddit.com/r/rust/comments/1j5vbn/rustdev_rfc_removing_t/
On Sat, Jul 27, 2013 at 4:51 PM, Gábor Lehel illiss...@gmail.com wrote
+1 for `for x in xs { }`
+1 for `in` as placement new, as far as I understand it
+1 for keeping `do` and `do 666.times { }`
+1 for `:` as type ascription (yay!)
On Thu, Jul 25, 2013 at 11:28 PM, Thad Guidry thadgui...@gmail.com wrote:
I also like 'do 10,times {' , since I likely would also use
On Sat, May 18, 2013 at 2:24 PM, Gábor Lehel illiss...@gmail.com wrote:
On Thu, May 16, 2013 at 7:58 PM, Graydon Hoare gray...@mozilla.comwrote:
I'm sympathetic to the desire here, as with all attempts to get
exceptions right. Sadly I've never really seen it; I don't think anyone
has
Hello list,
Currently Rust has different default visibilities in different places:
- `mod` items are private
- `struct` fields and `enum` variants are public
- `trait` methods are public
- `impl` methods are private
- `impls for` are public (by necessity)
I propose to change this to:
-
that you may be later beholden to
maintain.
Look at the tragedy of failing to use -fvisibility=hidden when building
shared libraries with gcc.
Best regards,
Mikhail
2013/5/30 Gábor Lehel illiss...@gmail.com
Currently Rust has different default visibilities in different places:
- `mod
On Wed, May 29, 2013 at 11:53 PM, Graydon Hoare gray...@mozilla.com wrote:
On 13-05-29 02:40 PM, Gábor Lehel wrote:
Maybe I'm unusual. But in C++ I'm always super-careful (one might say
anal retentive) about keeping my headers as clean of implementation
details as humanly possible. I don't
On Thu, May 16, 2013 at 7:58 PM, Graydon Hoare gray...@mozilla.com wrote:
I'm sympathetic to the desire here, as with all attempts to get
exceptions right. Sadly I've never really seen it; I don't think anyone
has really worked out the right way to work with catchable-exceptions in
a
On Fri, May 3, 2013 at 3:12 AM, Patrick Walton pwal...@mozilla.com wrote:
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
So this has been bouncing around in the back of my head, and now actual
thoughts have congealed there. Essentially, while I think this is a very
good defense of why Rust doesn't have purity, it's not so convincing to me
as a defense of why it *shouldn't* have purity. (I don't know if it was
On Tue, Apr 30, 2013 at 9:22 PM, Graydon Hoare gray...@mozilla.com wrote:
On 30/04/2013 11:26 AM, Gábor Lehel wrote:
Couldn't this be relaxed? In other words allow dynamically sized `str`
as a type (and perhaps similarly for other dynamically sized types), but
prohibit those things
On Wed, May 1, 2013 at 4:50 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Wed, May 01, 2013 at 02:39:12PM +0200, Gábor Lehel wrote:
So *if* the plan ends up working out, then taking the second part of my
earlier proposal:
You might also have a rule whereby dereferencing a variable when
On Tue, Apr 30, 2013 at 6:57 PM, Tim Chevalier catamorph...@gmail.comwrote:
On Mon, Apr 29, 2013 at 9:30 PM, Erik S sw...@earthling.net wrote:
On 4/29/2013 2:00 PM, Graydon Hoare wrote:
Yes. Formalizing and completing the definition of the constant
expression subgrammar would be extremely
On Sun, Apr 28, 2013 at 8:14 PM, Patrick Walton pwal...@mozilla.com wrote:
Is
there some way to make it just work, no matter what kind of strings
you're comparing? Perhaps foo == (*x) would work, for example?
That doesn't work, because it makes the dynamically sized `str` a type,
On Tue, Apr 30, 2013 at 8:27 PM, Patrick Walton pwal...@mozilla.com wrote:
On 4/30/13 11:26 AM, Gábor Lehel wrote:
Couldn't this be relaxed? In other words allow dynamically sized `str`
as a type (and perhaps similarly for other dynamically sized types), but
prohibit those things
1 - 100 of 112 matches
Mail list logo
