I'm sorry.
There is now a mode called by-copy, which was needed to make
constructors behave sensibly in the face of proper enforcement of
noncopyability. By-copy works just like by-move, except that when the
passed value is an lvalue, it is copied instead of moved (or, if it is
a type that can't
I pushed the new kind system today. Things to be aware of are:
- We now have proper copyability analysis, and resources can be used
in saner ways.
- The way arguments are passed to tag, object, and resource
constructors changed. See my other e-mail to the list.
- 'Last uses' of locals
On 18/11/2011 7:37 AM, Marijn Haverbeke wrote:
I'm sorry.
There is now a mode called by-copy, which was needed to make
constructors behave sensibly in the face of proper enforcement of
noncopyability.
Ok. How is it denoted? Your patch looks like it added + and possibly ++
or #? I can't quite
On 18/11/2011 10:39 AM, Graydon Hoare wrote:
Ok. How is it denoted? Your patch looks like it added + and possibly ++
or #? I can't quite tell.
Nevermind, got the tyencode / parser rules confused while reading.
-Graydon
___
Rust-dev mailing list
On 18/11/2011 11:30 AM, Brian Anderson wrote:
I'm worried that this rule is too clever. If I have some code like:
let a = whatever;
let v = variant(a);
then 'a' is moved into 'v'. If I change the code later to use 'a' again
after the initialization of 'v' then variant(a) becomes a copy. I
I somewhat share your worries about the cleverness of the
last-userule. But my logic for adding it anyway is: A) We need to do
thisanyway as an optimization, so B) if we are already doing it, we
mightas well remove the burden of explicitly annotating moves from the
userto the compiler. I still
I'm very concerned about these changes. Let's talk about this on Tuesday.
Dave
On Nov 18, 2011, at 10:55 AM, Marijn Haverbeke wrote:
I pushed the new kind system today. Things to be aware of are:
- We now have proper copyability analysis, and resources can be used
in saner ways.
- The
On 18/11/2011 1:12 PM, Jim Peters wrote:
Let's say I have a function parse_file(), it might fail because of I/O
problems or syntax failures, or it may give me back a valid parsed
object. Given that both errors may be detected at any depth in the
internal call tree, in another language
Has anyone considered haskell's monadic errors? As far as the end user
is concerned, it's pretty much equivalent to exceptions, but minus the
stack-jumping-ness of true exceptions. Since at it's heart it's just
returning values of eitherT,U, I would imagine it wouldn't break
typestate:
Graydon Hoare wrote:
To some extent. It depends a lot on the parsing task. I don't mean
to be dismissive. This is a great example. But I want to clarify
things:
- In a Serious Parser, errors are managed explicitly because error
reporting to the user is an Important Diagnostic Feature
On 11/18/2011 01:34 PM, Graydon Hoare wrote:
Sorry to blather on like this, but ... the point of lightweight
tasks in this language is that they're lightweight, and get used
early and often. If everyone's reaction to use a task is oh bother,
those are far too heavy, I think we've made a
A #do[] macro which just returns in the case of failure is basically equivalent
to this in practice, I think.
Niko
On Nov 18, 2011, at 2:18 PM, Erick Tryzelaar wrote:
Has anyone considered haskell's monadic errors? As far as the end user
is concerned, it's pretty much equivalent to
On Nov 18, 2011, at 4:51 PM, Niko Matsakis wrote:
1. You know exactly what the failure means and an exact, transparent
recovery mode. For this we recommend simply modeling the recovery
mode you want for expected-but-rare circumstances as arguments
passed *into* the callee,
13 matches
Mail list logo
