On 9/20/10 11:09 AM, Graydon Hoare wrote:
Is it possible to infer the type from the expression, e.g. in 2 + x
the 2 matches the declared type of x?
Plausible. Go takes a similar angle on this; their numeric literals are
untyped and acquire a type via inference from the context. I'm not
sure
I'm looking at the generated assembly code for std.rc (which is now
compiling, although it fails to link due to a strange mangling LLVM is
performing on duplicate native symbols). Even with all of LLVM's
optimizations, our hash insertion code has 4x the instruction count of
that of glib.
One
The current blocker for rustc self-hosting is writing out and reading
the crate metadata. Marijn wrote up a proposal outlining the data that
needs to be encoded on the wiki, which looks good to me. The code that
inserts the data blob into and reads the data blob from the files is
working,
Hi everyone,
I've been wondering for a while whether it's feasible from a performance
standpoint for a systems language to detect and abort on
potentially-dangerous integer overflows by default. Overflow is an
insidious problem for several reasons:
(1) It can happen practically anywhere;
On 04/24/2011 01:19 PM, Graydon Hoare wrote:
Thought everyone following along might want an update:
boot/rustboot builds a stage0/rustc that builds a functional
stage1/rustc that can, itself, build and pass about 60% of the testsuite
(174 tests); we cannot yet build stage1/libstd, nor
Currently rustrt is built with -O0 on the Mac due to a GCC bug. This is
starting to cause performance problems; in particular, very suboptimal
assembler is generated for next_power_of_two, which is the third-highest
function in the profiles. Apple's GCC is way outdated anyhow.
Will anyone
(rust-dev: This is an LLVM patch you might want to apply if you're
trying to build with clang on the Mac.)
Hi everyone,
I've got a quick patch to compiler-rt that makes it do a simple sanity
check on the toolchain before trying to compile for each architecture.
This makes clang able to be
On 5/12/11 9:44 AM, Marijn Haverbeke wrote:
I went ahead an implemented a large part of this--using a single colon
as a module separator, and downcasing the module names again. A
separate module namespace isn't done yet. Look around
https://github.com/marijnh/rust/tree/modulesep if you're
Hi John,
There is nothing preventing you from writing functions that take one
tuple parameter instead of multiple parameters. If you're faced with
library routines with signatures that aren't to your liking, it's simple
to write macros that tuple, untuple, curry, or uncurry parameters.
For
Hi everyone,
It occurred to me that our insistence on dynamic linking for the
standard library is likely to cause performance problems. This has been
lingering at the back of my mind for a while, although my fears have
been allayed to some degree so far by the fact that trivial standard
On 5/16/11 12:21 AM, Graydon Hoare wrote:
Two? It should only be one. Range calls block, block runs, range does +=
1, range calls block again. It's also not exactly a surprising indirect
function; it keeps calling the same one, from the same place in the code
+ stack. IOW it'll *probably* be
On 6/3/11 2:07 PM, Graydon Hoare wrote:
On 11-06-03 01:51 PM, Patrick Walton wrote:
Thoughts?
I like the line of reasoning; let me try phrasing in a slightly more
terse/pithy fashion:
Alias-formation must preserve unique ownership of the referent
Right, that's a good way to put
On 6/7/11 12:59 AM, Marijn Haverbeke wrote:
Unfortunately, there's this hole I mentioned before. What this
analysis guarantees is that the location pointed to by an alias will
always hold a value of type X — if you reassign to it, the alias will
still be valid. Except when going through a tag
On 7/7/11 7:03 AM, Marijn Haverbeke wrote:
Shall we specify that temporary values, when put into a data
structure, are moved, rather than copied? For non-temporary values,
this usually not what you want, so we should provide an explicit
operator to specify that we want to move those.
I was
Hi everyone,
Dave and I just whiteboarded ideas for function types, in light of the
issues that Andrew was seeing. We came to these tentative conclusions:
* Functions being noncopyable doesn't seem to work, because it breaks
bind. bind must copy the environment of the function bound to.
*
On 7/14/11 3:08 AM, Marijn Haverbeke wrote:
First, a relatively non-controversial case:
autoccx = cx.fcx.lcx.ccx; // Look ma, no refcounting bumps!
This case is very similar to alt/for blocks, and the alias checker
could check it with a relatively simple extension.
Next, of couse, I'm going
On 7/31/11 9:11 AM, Brendan Eich wrote:
JS already has function hoisting, which wins for programming in top-down style,
maintaining source without having to topologically sort functions, etc. I made
functions hoist to top of program or outer function body to mimic letrec, way
back in the
The lack of them makes destructuring assignment a lot less convenient...
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 8/11/11 4:10 PM, Marijn Haverbeke wrote:
As for destructuring, records seem to work very well there. In most
cases, you'll use the field names for your variables, so you get
simply
let {key, val} = someexpression();
Also, what I'd like to do is this:
let x, y = 1, 2;
I have to
So it turns out that dynamically-sized frames are quite tricky to get
right with GC. Essentially, when crawling the stack, the GC needs to
rerun all of the dynamic size and alignment calculations in order to
determine the layout of the frame so that it can find the roots. LLVM
has no support
On 08/13/2011 12:47 PM, Marijn Haverbeke wrote:
Where bailing out means it simply allocates more memory and doesn't
collect anything? I can imaging a long-running computation inside some
generic function 'leaking' until it runs out of memory.
Yup, it can definitely leak. We need to solve this
On 08/28/2011 07:10 PM, Graydon Hoare wrote:
Non on shared boxes. They might be cyclic, so it might not terminate.
We're no longer statically differentiating the cyclic from the acyclic.
Well, this prevents people from using the built-in = as the hash table
key comparison function in many
On 8/29/11 8:34 AM, Graydon Hoare wrote:
(Others: feel free to chime in, we've been back-and-forth on this issue
in conversation since ... years now?)
Dave suggested pointer equality only on mutable boxes, but deep equality
on immutable boxes. This might be a nice sweet spot.
Patrick
On 09/07/2011 07:18 AM, Marijn Haverbeke wrote:
While this is attractive from the perspective of having the
right defaults, it also makes the semantics of the code at a glance more
subtle.
The semantics are not effected at all -- both with 'structurally
immutable' and with immediate values, it
On 9/9/11 9:14 AM, Marijn Haverbeke wrote:
Update: The approach sketched earlier does not work out because it is
possible for a function to take a parameterized type without the
caller knowing that it does. (For example, a fnT(x: fn(T)), when
given a function fn(int), will call it with the
On 9/14/11 10:55 AM, Marijn Haverbeke wrote:
Thoughts?
So do you intend to make bracey-if a statement? What about
expression-alt? That'd still have the current awkwardness when
followed by '(' or '['.
Oh right, alt too. Maybe ML-style alt as well:
let x = alt y of some(z) { z } |
On 9/14/11 11:00 AM, Graydon Hoare wrote:
General responses:
- The if/then/else form of if-exprs will not satisfy ternary users,
I imagine, and requires a bunch of lookahead to find the 'then';
I don't particularly like the look of it.
- Doesn't solve 'alt', does it?
- Still requires the do {
On 9/14/11 11:10 AM, Patrick Walton wrote:
Fair enough; if others don't like separate expression and statement
forms, I'd vote for |val| for block-expression, without the |res| (it's
an interesting idea, but I'm not sure it's necessary -- maybe something
to think about for future versions?) I
On 9/16/11 2:10 PM, Marijn Haverbeke wrote:
The problem: Accessor functions always have to copy their return
value, so you can't efficiently get at the content of data structures
(except by duplicating the logic needed to access them).
The original solution proposed was to pass the accessor a
On 9/16/11 2:40 PM, Patrick Walton wrote:
fn get_swapT(mutable optionT : opt) - T {
let opt2 = none;
opt :=: opt2;
ret alt opt2 { none. { fail } some(x) { x } }
}
Sorry, this should read:
fn get_swapT(mutable opt : optionT) - T {
let opt2 = none;
opt :=: opt2;
ret
On 9/17/11 11:59 AM, Marijn Haverbeke wrote:
- The implicit, clever approach: Notice that the only situation where
you want to do this is when using a local variable (you can't move out
of data structures) for the last time, and simply make the compiler
optimize the last use of a variable into a
Minor thing: What is the purpose of |put;| (with no arguments)?
Just curious.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
It would be nice if we could figure out what to do about iterators for
0.1. I was thinking that we could make them Java-style iterators -- that
is, objects with has_next() : bool and next() : T methods. |for each|
would simply be syntactic sugar.
This form:
for each (x in iter()) {
On 9/28/11 5:27 PM, Brendan Eich wrote:
On principle I do not want us to go down this path, even if we change later. It
adds risk that we won't change. It imposes a stateful model on iterators where
has_next and next must be coherent, and you have to write two methos (not one
as in Python or
On 9/29/11 5:20 AM, Peter Hull wrote:
On Thu, Sep 29, 2011 at 5:17 AM, Graydon Hoaregray...@mozilla.com wrote:
- I prefer the closure-passing form:
With this form, would it be possible to extract more than one value
per loop - for example if I had a sequence of numbers that I wanted to
pair
On 9/28/11 9:17 PM, Graydon Hoare wrote:
- Expresses the iteratee is aliased during iteration fact to the
alias-checker, so you don't have to worry about invalidating
externalized iterators. This is important; particularly if you want
to exploit next part ...
I don't understand this, sorry...
On 9/29/11 5:25 AM, Marijn Haverbeke wrote:
I guess we could use return-by-alias here, yes. I was kind of assuming
everybody hated that and wanted it to go away. But if we use that we
can no longer return a tag to indicate end of sequence (you can't
currently wrap a reference in a data structure
On 9/29/11 5:46 AM, Marijn Haverbeke wrote:
I still consider using swap to return things an absolute non-solution.
Try writing some code in that style. Unless I'm missing some part of
the way you want to approach this, it's absolutely dreadful to work
with.
If swap is unacceptable, then, as
On 9/29/11 4:51 PM, Graydon Hoare wrote:
I think this is probably less of a worry than you're seeing; the new
rust abi is probably by reference, but by value in some cases. It only
has the freedom to choose when it's unobservable to safe code anyways
(when it's an immutable value). So the values
C stacks are starting to make their way into rustc. This is a
prerequisite for stack growth -- C code can't in general be expected to
perform stack growth checks, so we need to reserve a large stack for it
(one per thread, in the current implementation). Right now C stack usage
is implemented
On 9/29/11 11:00 AM, Graydon Hoare wrote:
- Write 1 iter interfaces on most collections, with varying
strategies, to reduce unwanted boilerplate in cases you don't
need it. Cold code is cold, harmless.
vec::each(v) == takes fn(e) - (), returns ()
vec::scan(v) == takes fn(e) - bool, returns ()
On 9/30/11 12:14 AM, Marijn Haverbeke wrote:
Now that every parameter is passed by reference, our ABI is no longer
compatible with C.
Are you talking about calling C functions from rust, or calling rust
from C? In the first case, we are generating a wrapper anyway, which
currently makes sure
On 9/30/11 8:37 AM, Patrick Walton wrote:
On 9/30/11 12:14 AM, Marijn Haverbeke wrote:
Are you talking about calling C functions from rust, or calling rust
from C? In the first case, we are generating a wrapper anyway, which
currently makes sure things are passed by value.
Not anymore
I think native types might have outlived their usefulness at this point.
We can represent them as ints, and their type safety can be achieved via
tags.
So
native mod ... { type ModuleRef; }
becomes
tag ModuleRef = int;
This has the nice benefit of being able to use sizes other than words;
On 10/29/2011 05:06 AM, David Rajchenbach-Teller wrote:
I disagree. I would expect print to be something that writes to
stdout. As I understand it, log is a specialised debug/trace facility
which is built-in and configurable. For example if you write log
hello world it won't print anything
As a newbie, I do not mind either way between importing std::io or
having the function baked in a Pervasives/Prelude module. However, I
concur that log is probably not the right tool for Hello world.
Looks like it's decided. Filed a bug to get us a Pervasives module:
On 10/30/2011 01:53 PM, David Rajchenbach-Teller wrote:
If type `str` is indeed (at least partly) mutable, each of these
functions must copy the `str`, which is rather costly. I wonder if
there is a type-based mechanism that I could use to guarantee that a
`str` is never mutated, hopefully some
We recently renamed libstd.so to libruststd.so to avoid stomping on a
libstd that might exist in /usr/lib. Perhaps we should attack this in a
more holistic way: either (a) all Rust libraries should start with rust*
or (b) Rust libraries should install themselves into /usr/lib/rust.
The latter
I agree. log_err was a kludge and I'd prefer to un-kludge it before
shipping rather than adding another keyword. Multiple log-levels is the
way to go. Macro if there's something relatively easy, or just keep
'log' as compiler-supported, but extend the syntax and include a bunch
of log-level
On 11/8/11 9:41 AM, Graydon Hoare wrote:
Likely yes. Though we should offer a compiler flag / crate attribute to
disable the auto-import of it.
In fact, we'll have to, in order to bootstrap.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 11/8/11 9:12 AM, David Rajchenbach-Teller wrote:
Does this mean that we can only have one constructor?
If we wish to have several constructors – and if we accept that they
must not have the same name – the class could yield a full module, in
which each constructor is a function.
Yeah, we
On 11/11/2011 07:29 AM, Niko Matsakis wrote:
In principle, it might be nice to allow something like bounded polymorphism:
fn call_fooT:has_foo(x: T) {
x.foo();
}
Without subtyping, it would make less sense. Perhaps it corresponds
to
passing the vtable that converts a `T`
On 12/04/2011 02:02 PM, Graydon Hoare wrote:
Cross-crate inlining (when and if we do it) is a mixed blessing anyways.
It hurts data and procedural abstraction -- both virtues of proper
software design -- in order to help compile-time (but not run-time)
modularity. I'm happy to experiment with
On 1/9/12 5:36 PM, Tim Chevalier wrote:
The problem the paper addresses is in Haskell, where having multiple
instances in scope for the same class and type can cause unpredictable
behavior. (The paper explains the basic problem in more detail pretty
well.) It seems like there's an analogous
I broke zero-variant tags with my syntax change. Is this something we
want to support?
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 1/25/12 10:42 AM, Matthew O'Connor wrote:
Hi,
I was reading https://github.com/mozilla/rust/wiki/Bikeshed-tailcall and
wondered about the statement Tail calls cannot be implemented in
general without a serious performance hit for all calls. I've never
heard this before. tjc speculated it had
On 1/25/12 11:46 AM, Marijn Haverbeke wrote:
Currently it is simply '+'.
The thing that prompted this is issue #1520 -- operator overloading.
Delegating + on non-builtin-numeric types to a `num` interface that
implements methods add/sub/mult/div/rem/neg methods seems elegant, and
similar to
On 1/26/12 6:35 PM, Kevin Atkinson wrote:
As a potential user of the language, I have to agree with Graydon. In
particular I do not like the idea of having to use a different symbol
for what I see as method access and field access.
Ok, let's not do it then.
Patrick
On 02/04/2012 06:21 AM, Arne Döring wrote:
The second suggestion is concerning tho #fmt macro. #fmt works like
printf, but its string is parsed at compile time, so that errors might
be thrown when the string is incorrect. So when you unwind this format
string at compile time, you know also all
On 2/7/12 4:23 PM, Graydon Hoare wrote:
Hm. I am confused at the description of the hole in the type system. I
was under the impression that this was the distinction between immutable
values and immutably-rooted values (those contained within a
path-of-immutable-references). Am I
Ah yes, I remember now.
Can this also be used to break refinement types (i.e. break typestate)? We have
subtyping via refinements.
Patrick
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Niko Matsakis n...@alum.mit.edu wrote:
On 2/7/12 4:27 PM, Patrick Walton wrote
On 02/08/2012 06:54 AM, Marijn Haverbeke wrote:
Yes. What would be legal would be:
let x = @{a: 10};
x = @{a: 20};
That seems a rather heavy-handed restriction.
C++ has the same restriction. In practice I've found that it rarely
comes up.
Patrick
On 02/08/2012 08:48 AM, Marijn Haverbeke wrote:
C++ has the same restriction. In practice I've found that it rarely comes
up.
Obviously, since const field are rare in C. In Rust, one rarely uses a
record type that doesn't have immutable fields.
Fair enough. Still:
(1) This is a type
On 02/20/2012 11:44 AM, Ted Horst wrote:
Is there a better way to do this in rust?
I think this is the sincerest form of a feature request for const
vectors. :)
There's a bug on it here: https://github.com/mozilla/rust/issues/571
Patrick
___
On 03/03/2012 10:34 AM, tav wrote:
My language of choice for systems development in recent times has been
Go. However, whilst it has excellent networking support, Go's
stop-the-world garbage collector gets in the way of the needs of an
in-memory datastore.
I understand that Rust would be give
On 3/19/12 6:56 PM, Tim Chevalier wrote:
I don't think we have any plans to add implicit casts as implied by
your other 4 examples. It seems too complex -- if any of the variables
in your example were mutated after being initialized, the pass that
would insert these casts would get pretty
I like all of this.
On 3/23/12 1:42 PM, Graydon Hoare wrote:
Are the semantics over-complex? I think we really have a large number of
use-cases and there's no way we can hit them all with a single
abstraction. Shared-heap != unique-heap != constant != alloca !=
borrowed region, and fixed-size
On 3/23/12 6:54 PM, Graydon Hoare wrote:
On 12-03-23 06:47 PM, Sebastian Sylvan wrote:
On Fri, Mar 23, 2012 at 1:42 PM, Graydon Hoaregray...@mozilla.com wrote:
- [1,2,3,4,5]-- constant memory, type [int]
- [1,2,3,4,5]/5 -- constant memory, type [int/5]
Hmm, why couldn't
On 03/25/2012 02:16 AM, Gareth Smith wrote:
On 23/03/12 20:42, Graydon Hoare wrote:
- Existing vecs are always unique. Sometimes you want shared, but
boxing them as @[] causes double-indirection, feels awkward.
Apologies if I am missing the point here, but how about using some sort
of
On 04/07/2012 04:08 AM, Grahame Bowland wrote:
For the case of one big data structure multiple workers want to read
from, couldn't we write a module to do this within the language as it
stands? The module could take a unique reference (which can't contain
anything mutable), then issue (via
On 04/08/2012 11:15 AM, Kobi Lurie wrote:
hi rust list, is there something like Console.ReadLine in rust?
I want to experiment, get a feel for the language by writing a little
hangman game.
Check out the io module: http://doc.rust-lang.org/doc/core/io.html
In particular use stdin() to get a
Here's a total bikeshed. Apologies in advance:
There's been some criticism of Rust's syntax for being too brace-heavy.
I've been thinking this for a while. Here's a minimal delta on the
current syntax to address this:
Examples:
// before:
if foo() == bar { 10 } else { 20 }
On 04/15/2012 06:17 PM, Sebastian Sylvan wrote:
Could tail calls work? I.e. each label would equal a separate
function (any state would have to be passed through), and then you'd
just keep tail-calling from state to state. Without really knowing
exactly what kind of code you're trying to
On 4/16/12 11:46 AM, Graydon Hoare wrote:
They're already present (were from the beginning) but they broke when
we shifted from rustboot (hand-rolled code generator) to rustc (LLVM).
It turns out that you have to adopt a somewhat pessimistic ABI in all
cases if your functions are to be
Here's a little before-and-after with some of the syntax and semantic
changes discussed (snippet from Sebastian Sylvan's raytracer [1] and
modified slightly):
--- Before ---
#[inline(always)]
fn get_rand_env() - rand_env {
let rng = rand::rng();
let disk_samples =
On 04/17/2012 10:03 PM, David Piepgrass wrote:
This requires arbitrary lookahead to disambiguate from tuples.
This bit in particular. Really really don't want to cross the bridge to
arbitrary lookahead in the grammar.
Pardon me, but I'm not convinced that there is a problem in
On 4/18/12 5:07 PM, Jeff Schultz wrote:
Any reason we can't just have an empty '||' instead of the '-'?
It's easier to type and makes it easier to find all closures.
|| looks a little like line noise to me, although I'm not wedded to the
thin arrow.
spawn(): - {
log(Hi!);
}
On 04/21/2012 10:28 AM, gasche wrote:
I've been wondering about a problem tightly related to named
Re. function types: if you consider those parameter-passing structures
as first class (which does necessarily mean that they are convenient
to use, for example if they're not adressable they will
On 04/28/2012 03:17 AM, Matthieu Monrocq wrote:
I would also like to point out that if it's an implementation detail,
the actual representation might vary from known size to unknown size
without impact for the user, so starting without for the moment because
it's easier and refining it later is
On 05/01/2012 12:53 AM, Florian Weimer wrote:
* Sebastian Sylvan:
R. Shahriyar, S. M. Blackburn, and D. Frampton, Down for the Count?
Getting Reference Counting Back in the Ring, in Proceedings of the
Eleventh ACM SIGPLAN International Symposium on Memory Management,
ISMM ‘12, Beijing, China,
On 5/1/12 8:59 AM, Matthieu Monrocq wrote:
I agree that the technics outlined, especially with the details on their
advantages/drawbacks are a very interesting read.
As for the predictable timing, anyway it seems hard to have something
predictable when you take cycle of references into account:
On 5/4/12 2:57 PM, Niko Matsakis wrote:
I had a crazy thought for how to make method call syntax unambiguously
distinguishable from field access without making it ugly.
In short: make `a.b(c, d)` *always* a method call, rather than parsing
it as a call to a value stored in a field. If you
On 05/20/2012 05:23 AM, Bennie Kloosteman wrote:
New member to the list im no genius but am looking for a replacement
for c for system programming.
1) Great work on UTF8 strings and USC4 chars ( I do some work with
chinese chars and USC-2 just doesn't work here) . BTW why null
terminated
On 5/25/12 10:16 AM, David Rajchenbach-Teller wrote:
What's the difference between |scope| and Rust's resources, exactly?
scope would be executed unconditionally at the end of the current
block, while the rules for standard Rust RAII are somewhat more complex
and depend on the initedness of
On 5/25/12 10:28 AM, Patrick Walton wrote:
There's a hidden dynamic flag created by the compiler
Hit send too early. There's a hidden dynamic flag created by the
compiler to track initedness for each variable.
Patrick
___
Rust-dev mailing list
On 06/02/2012 06:30 AM, Gareth Smith wrote:
Does this proposal have any hope?
I agree completely and have thought the exact same thing in the past. I
will bring this up at the next meeting.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
Hi everyone,
Here's a revised lambda syntax tweak proposal. It's gotten feedback from
several, so I think it's time to present it more generally.
I don't think we should do this now; we should remain focused on bugs
for 0.3. I'm just interested in getting feedback.
Executive summary of the
On 6/6/12 10:23 AM, Graydon Hoare wrote:
I'd also possibly prefer break rather than continue to get an
early-exit from a 'do'. But then, we're still debating what to do for
the word continue in the grammar anyway (#2229, I still prefer loop;
there!)
Sure, either one works for me. I don't
On 6/6/12 10:52 AM, Sebastian Sylvan wrote:
Just a quick question: Can I pass in a multi-statement lambda to a
function without using do or for, and if so what does it look
like?
I'm guessing something like this, but I didn't see it spelled out:
foo( |x| {
let y = x+1;
y+1
});
Yep,
On 6/7/12 2:20 PM, Gareth Smith wrote:
I think that allowing an early exit with a break/continue from lambdas
that use this special form is confusing, because breaking may or
may-not actually resume the code that follows the do-call. The lambda
might be put into a data structure for later
On 6/7/12 1:41 PM, Gareth Smith wrote:
Hi Rust-Dev,
I have recently (using the latest rust from github) encountered some new
warnings about implicitly copying a non-implicitly-copyable value. I
believe this is due to the fix for
https://github.com/mozilla/rust/issues/2450.
This warning seems
On 6/7/12 10:27 PM, David Rajchenbach-Teller wrote:
I believe that this snippet has a more immediately visible structure
than the original and is easier to read, while the syntax tweak is
trivial to compile.
What do you think?
How about a Scheme-like cond macro?
Patrick
On 06/10/2012 08:08 AM, Niko Matsakis wrote:
This was also posted on my blog, but I wanted to make sure people saw
it, as I'd like to discuss this on Tuesday, because one of the logical
next steps for the regions work is to begin deciding precisely what to
do about the types of identifiers in
On 06/10/2012 12:14 PM, Graydon Hoare wrote:
On 10/06/2012 11:30 AM, Patrick Walton wrote:
I like this. The only concern, as a comment pointed out, is that *
might be slightly confusing; maybe ref is better.
I like it too. Though I wonder if the ambiguity between
-as-a-reference-taker
On 6/12/12 3:28 PM, Niko Matsakis wrote:
It's a good point that *unsafe.T is rather noisy. I thought that was ok,
but I wasn't thinking about the fact that it will appear often in FFIs.
I am not sure how this would work out in practice. As you say, region
ptrs in argument position are ok, but
On 6/13/12 6:37 PM, Niko Matsakis wrote:
On 6/12/12 3:33 PM, Graydon Hoare wrote:
Try sketching some code in a buffer, see how it looks. Might be
possible to come up with an abbreviation (!T perhaps, or the old
unused sigil ?T maybe?), might be possible for inference and a couple
rules about
On 6/14/12 10:23 AM, Graydon Hoare wrote:
What disappoints me about all this is that the language is now dependent
on unsafe library code in order to do asymptotically fast aggregate
types at all. The += optimization and vec doubling-allocation was the
one primitive related to aggregate types
On 6/14/12 1:41 PM, Graydon Hoare wrote:
However, we nicely dodged that bullet by not supporting ++ and -- at
all. Very prescient :)
Not really. Reoccurs with foo[bar] += 1;
Well, there's a fairly straightforward desugaring: foo[bar] =
foo[bar] + 1; For ++ it's less certain (you have to
On 6/14/12 4:01 PM, Graydon Hoare wrote:
I actually think if you're going to go down that road you want * to be
unsafe as it is now, and ^ to be your region pointer. That has both more
precedent in other languages and, looking at the above examples, is a
bit less visually noisy.
Bonus
On 06/16/2012 07:30 AM, Niko Matsakis wrote:
Jumping back to an old thread:
Yes, except that continue/break/ret would be valid in the latter but
not the former.
It seems like we should allow continue or break but not both. And it
seems mildly inconsistent to allow breaks in a `do` but not
1 - 100 of 608 matches
Mail list logo
