On Sun, 26 May 2013 18:56:58 -0400, Timothee Cour
thelastmamm...@gmail.com wrote:
In fact it's also possible to know that these don't return a reference
to
their parameter.
Watch out for this:
Struct S {double x;}
ref double foo(ref S a){return a.x;}
That case is covered by the proposal.
On 05/05/2013 12:30 AM, Walter Bright wrote:
On 5/4/2013 3:03 PM, deadalnix wrote:
Where you miss the point, is that these annotations may be omitted
(and they
are most of the time). When nothing is specified, the lifetime of the
returned
reference is considered to be the union of the
In fact it's also possible to know that these don't return a reference to
their parameter.
Watch out for this:
Struct S {double x;}
ref double foo(ref S a){return a.x;}
This sounds hacky. I've proposed a general solution here:
http://wiki.dlang.org/DIP38
either with user annotations of
On 04.05.2013 20:33, Walter Bright wrote:
Static Compiler Detection (in @safe mode):
1. Do not allow taking the address of a local variable, unless doing a
safe type 'paint' operation.
I'm not exactly sure what a safe type paint operation does, and
whether the following has already been
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Thanks to the many recent threads on this, and the dips on it,
everyone was pretty much up to speed and ready to find a
resolution. This resolution only deals with the memory safety
issue.
...
What if an argument is captured by a
On Thursday, May 09, 2013 21:30:00 Rainer Schuetze wrote:
On 04.05.2013 20:33, Walter Bright wrote:
Static Compiler Detection (in @safe mode):
1. Do not allow taking the address of a local variable, unless doing a
safe type 'paint' operation.
I'm not exactly sure what a safe type
On 5 May 2013 10:37, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote:
On 5/4/13 7:31 PM, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a ref parameter will automagically work with r-values?
Yes.
This is new to me. My
On Monday, May 06, 2013 10:16:57 Steven Schveighoffer wrote:
Could be the time change, haven't rebooted my Mac since flying back. My
clock is correct, but Opera may be confused.
Oh, the wonders of dealing with time... :)
- Jonathan M Davis
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Static Compiler Detection (in @safe mode):
1. Do not allow taking the address of a local variable, unless
doing a safe type 'paint' operation.
2. In some cases, such as nested, private, and template
functions, the source is
On Sunday, 5 May 2013 at 02:36:45 UTC, Jonathan M Davis wrote:
As it is, we arguably didn't choose the best defaults with the
attributes that
we have (e.g. @system is the default instead of @safe, and
impure is the
default instead of pure). The result is that we have to use a
lot of
On Sat, 04 May 2013 19:30:21 -0700, Jonathan M Davis jmdavisp...@gmx.com
wrote:
However, if we had an attribute which explicitly designated that a
function
accepted both rvalues and lvalues (which is what auto ref was originally
supposed to do as Andrei proposed it), then if you saw
auto
On 5/6/13 12:10 PM, Steven Schveighoffer wrote:
The counter argument:
foo(makeRvalue()); // error: cannot pass rvalues to ref
// programmer: WTF? This is stupid, but ok:
auto x = makeRvalue();
foo(x);
In other words, explicit nops aren't any better than implicit nops. Even
if we *require*
On Mon, 06 May 2013 06:43:38 -0700, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think we can technically make the overloading work while also allowing
binding rvalues to ref. But that wouldn't help any. Consider:
ref int min(ref int a, ref int b) { return b a ? b : a; }
...
On 5/6/13 12:48 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 06:43:38 -0700, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think we can technically make the overloading work while also
allowing binding rvalues to ref. But that wouldn't help any. Consider:
ref int min(ref
On 5/6/13 12:48 PM, Steven Schveighoffer wrote:
(your clock seems to be messed up)
Andrei
On Mon, 06 May 2013 10:07:01 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 12:48 PM, Steven Schveighoffer wrote:
(your clock seems to be messed up)
Andrei
Could be the time change, haven't rebooted my Mac since flying back. My
clock is correct, but Opera may
On Mon, 06 May 2013 10:05:48 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 12:48 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 06:43:38 -0700, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think we can technically make the overloading work
On 5/6/13 10:31 AM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 10:05:48 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 12:48 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 06:43:38 -0700, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think
On Mon, 06 May 2013 10:40:06 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 10:31 AM, Steven Schveighoffer wrote:
By completely innocuous you mean valid? I don't think the above is
valid.
I meant valid-looking.
OK.
It seems to compile and work for me, but
On 5/6/13 11:12 AM, Steven Schveighoffer wrote:
If x 100, the code is saving a reference to a destroyed temporary.
If you couldn't see it, how many do you expect would see similar
issues in even simpler and cleaner D code?
No, I was wondering whether the compiler detects this and keeps the
On 5/6/13 11:31 AM, Andrei Alexandrescu wrote:
struct A {
A(const T x) : a(x) {}
const T a;
};
In _this_ case, initializing A with an rvalue of type T compiles and
subsequently runs with undefined behavior.
I should add I've seen this bug several times (causing mysterious
crashes) several
On Monday, 6 May 2013 at 13:43:38 UTC, Andrei Alexandrescu wrote:
I think we can technically make the overloading work while also
allowing binding rvalues to ref. But that wouldn't help any.
Consider:
ref int min(ref int a, ref int b) { return b a ? b : a; }
...
int x;
fun(min(x, 100));
On 5/6/13 11:34 AM, deadalnix wrote:
On Monday, 6 May 2013 at 13:43:38 UTC, Andrei Alexandrescu wrote:
I think we can technically make the overloading work while also
allowing binding rvalues to ref. But that wouldn't help any. Consider:
ref int min(ref int a, ref int b) { return b a ? b : a;
On Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 11:12 AM, Steven Schveighoffer wrote:
If x 100, the code is saving a reference to a destroyed temporary.
If you couldn't see it, how many do you expect would see similar
issues in even
On Monday, 6 May 2013 at 15:39:07 UTC, Andrei Alexandrescu wrote:
Yes, because it's dynamically checked.
The check will see that the reference is in the current stack
frame and pass.
On 5/6/13 11:52 AM, deadalnix wrote:
On Monday, 6 May 2013 at 15:39:07 UTC, Andrei Alexandrescu wrote:
Yes, because it's dynamically checked.
The check will see that the reference is in the current stack frame and
pass.
No. The check will fail (unless wrongly written).
Andrei
On 5/6/13 11:48 AM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Consider the body of min isn't known (eliminate templates etc). Then
what the compiler sees is a function call that returns a const ref.
All it can assume
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 11:48 AM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Consider the body of min isn't known (eliminate templates
On Mon, 06 May 2013 09:43:38 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
ref int min(ref int a, ref int b) { return b a ? b : a; }
...
int x;
fun(min(x, 100));
Here the result of min may be bound to an lvalue or an rvalue depending
on a condition. In the latter case,
On Monday, 6 May 2013 at 16:03:51 UTC, Andrei Alexandrescu wrote:
On 5/6/13 11:52 AM, deadalnix wrote:
On Monday, 6 May 2013 at 15:39:07 UTC, Andrei Alexandrescu
wrote:
Yes, because it's dynamically checked.
The check will see that the reference is in the current stack
frame and
pass.
On 5/6/13 12:17 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
No. It's a very different thing handled by a special rule in C++.
This isn't helping. You keep saying its different but not how.
In one case a
On 5/6/13 12:20 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 09:43:38 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
ref int min(ref int a, ref int b) { return b a ? b : a; }
...
int x;
fun(min(x, 100));
Here the result of min may be bound to an lvalue or an rvalue
On Mon, 06 May 2013 13:28:18 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 12:17 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
No. It's a very different thing handled by a special rule
On 5/6/13 1:45 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 13:28:18 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 12:17 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
No. It's a
On Mon, 06 May 2013 13:53:10 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/6/13 1:45 PM, Steven Schveighoffer wrote:
This is a trimmed down example:
int foo(int val) { return val; }
What I read from you (and I could be wrong) is you are saying this is
not valid:
On Monday, 6 May 2013 at 14:05:48 UTC, Andrei Alexandrescu wrote:
template class T const T min(const T a, const T b) {
return b a ? b : a;
}
...
int x = ...;
auto weird = min(x, 100);
What I see going on is an attempt to double up on the use of ref
for twp conflicting purposes. Perhaps
On 5/6/2013 8:31 AM, Andrei Alexandrescu wrote:
In _this_ case, initializing A with an rvalue of type T compiles and
subsequently runs with undefined behavior.
This is why D does not allow ref as a storage class for variables.
On Sunday, May 05, 2013 06:10:34 David Nadlinger wrote:
On Sunday, 5 May 2013 at 02:36:45 UTC, Jonathan M Davis wrote:
Don was complaining that one reason that moving
to D2 at Sociomantic looks unappealing in spite of the benefits
is the fact
that they're going to have to add so many
On Sunday, 5 May 2013 at 07:22:06 UTC, Jonathan M Davis wrote:
Now, I argued that pure's primary benefit isn't really in
optimizations but
rather in the fact that it guarantees that your code isn't
accessing global
state, but there's still the general concern that there's a lot
of new
On 2013-05-04 20:33, Walter Bright wrote:
These checks would be omitted if the -noboundscheck compiler switch was
provided.
Perhaps a new flag for this.
--
/Jacob Carlborg
On Sunday, 5 May 2013 at 09:26:54 UTC, Jacob Carlborg wrote:
On 2013-05-04 20:33, Walter Bright wrote:
These checks would be omitted if the -noboundscheck compiler
switch was provided.
Perhaps a new flag for this.
Or just rename it in more general -noruntimesafetychecks
On 2013-05-04 18:33:10 +, Walter Bright newshou...@digitalmars.com said:
Runtime Detection
There are still a few cases that the compiler cannot statically detect.
For these a runtime check is inserted, which compares the returned ref
pointer to see if it lies within the stack frame of
On Sunday, 5 May 2013 at 00:47:00 UTC, Walter Bright wrote:
If the compiler accepts that code, it will crash at runtime. If
it doesn't accept that code, then it will also disallow
legitimate code like:
ref T foob(ref U u) { static T t; return t; }
ref T bar() { U u; return foob(u);
On 5/5/2013 4:43 AM, Michel Fortin wrote:
On 2013-05-04 18:33:10 +, Walter Bright newshou...@digitalmars.com said:
Runtime Detection
There are still a few cases that the compiler cannot statically detect. For
these a runtime check is inserted, which compares the returned ref pointer to
On 2013-05-05 18:19:26 +, Walter Bright newshou...@digitalmars.com said:
On 5/5/2013 4:43 AM, Michel Fortin wrote:
On 2013-05-04 18:33:10 +, Walter Bright newshou...@digitalmars.com said:
Runtime Detection
There are still a few cases that the compiler cannot statically detect. For
On Sunday, 5 May 2013 at 23:45:21 UTC, Michel Fortin wrote:
Just rethrowing an idea that was already thrown here: support
annotated lifetimes *in addition* to this runtime detection
system. Those who use manual memory management will need it to
make their code @safe. Those who stick to the GC
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Thanks to the many recent threads on this, and the dips on it,
everyone was pretty much up to speed and ready to find a
resolution. This resolution only deals with the memory safety
issue.
And to anybody who couldn't make it to
On 5/4/13 2:56 PM, David Nadlinger wrote:
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Thanks to the many recent threads on this, and the dips on it,
everyone was pretty much up to speed and ready to find a resolution.
This resolution only deals with the memory safety issue.
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Runtime Detection
There are still a few cases that the compiler cannot statically
detect. For these a runtime check is inserted, which compares
the returned ref pointer to see if it lies within the stack
frame of the exiting
Runtime Detection and opt-out with -noboundscheck is a stroke
of genius!
Thanks. ;-)
Araq wrote in January:
You can also look at how Algol solved this over 40 years ago:
Insert a runtime check that the escaping reference does not point
to the current stack frame which is about to be
On 5/4/13 4:15 PM, Araq wrote:
Runtime Detection and opt-out with -noboundscheck is a stroke of
genius!
Thanks. ;-)
Araq wrote in January:
You can also look at how Algol solved this over 40 years ago:
Insert a runtime check that the escaping reference does not point
to the current stack
So just to be clear, ref parameters can now take rvalues?
There's one minor problem I see with this:
S currentVar;
void makeCurrent(ref S var) {
currentVar = var;
}
makeCurrent(getRValue());
If makeCurrent knew that var was an rvalue it could avoid
calling postblit on currentVar, because
On 5/4/2013 1:20 PM, Andrei Alexandrescu wrote:
On 5/4/13 4:15 PM, Araq wrote:
Runtime Detection and opt-out with -noboundscheck is a stroke of
genius!
Thanks. ;-)
Araq wrote in January:
You can also look at how Algol solved this over 40 years ago:
Insert a runtime check that the escaping
You mean DIP 36, not DIP 35. ;)
Any estimates as to when the whole is implemented?
So dmd 2.064, 2.070, etc.?
On Saturday, 4 May 2013 at 19:40:36 UTC, Tove wrote:
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Runtime Detection
There are still a few cases that the compiler cannot
statically detect. For these a runtime check is inserted,
which compares the returned ref pointer to see
On 5/4/2013 2:22 PM, deadalnix wrote:
I still think this is inferior to Rust's solution and like to see ref as a
equivalent of the Rust burrowed pointer. It achieve the same safety at compile
time instead at runtime, and incurs no extra complexity except in some very rare
cases (when you have a
On Saturday, 4 May 2013 at 21:48:25 UTC, Walter Bright wrote:
On 5/4/2013 2:22 PM, deadalnix wrote:
I still think this is inferior to Rust's solution and like to
see ref as a
equivalent of the Rust burrowed pointer. It achieve the same
safety at compile
time instead at runtime, and incurs no
On Saturday, 4 May 2013 at 21:57:14 UTC, deadalnix wrote:
On Saturday, 4 May 2013 at 21:48:25 UTC, Walter Bright wrote:
On 5/4/2013 2:22 PM, deadalnix wrote:
I still think this is inferior to Rust's solution and like to
see ref as a
equivalent of the Rust burrowed pointer. It achieve the same
On 5/4/2013 3:03 PM, deadalnix wrote:
Where you miss the point, is that these annotations may be omitted (and they
are most of the time). When nothing is specified, the lifetime of the returned
reference is considered to be the union of the lifetime of parameters
lifetime, which is what you want
To put it another way, we wish to solve the problem without introducing more
annotations. Rust's solution requires additional annotations, and so is not what
we're looking for.
These checks would be omitted if the -noboundscheck compiler
switch was provided.
This reminds me of Tony Hoare's lecture on null references being
a billion dollar mistake. He mentioned that he asked his Algol
customers if they wanted the option to disable array bounds
checking, and they all
On Saturday, 4 May 2013 at 22:33:58 UTC, Walter Bright wrote:
To put it another way, we wish to solve the problem without
introducing more annotations. Rust's solution requires
additional annotations, and so is not what we're looking for.
Require isn't the right word, or you hav to explain
On 5/4/13, Walter Bright newshou...@digitalmars.com wrote:
Andrei I argued that we needed to make it work with just ref annotations.
So to recap, 2.063 turns slices into r-values which will break code
that used ref, e.g.:
-
void parse(ref int[] arr) { }
void main()
{
int[] arr = [1,
On 5/4/2013 3:50 PM, deadalnix wrote:
Require isn't the right word, or you hav to explain yourself much more.
You need an explicit annotation if a ref parameter is returned by ref by that
function. This is what Rust's annotations do.
Consider:
ref T foob(ref U u) { return u.t; }
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a ref parameter will automagically work with r-values?
Yes.
On 5/4/2013 4:03 PM, Andrej Mitrovic wrote:
On 5/4/13, Walter Bright newshou...@digitalmars.com wrote:
Andrei I argued that we needed to make it work with just ref annotations.
So to recap, 2.063 turns slices into r-values which will break code
that used ref, e.g.:
-
void parse(ref
On Saturday, 4 May 2013 at 23:31:39 UTC, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a ref parameter will automagically work with
r-values?
Yes.
This is good, but not I'm a bit bitter with the whole code
breakage of slice are
On 5/4/2013 4:34 PM, Walter Bright wrote:
And later down the road, maybe even in 2.064, ref will take r-values
making the new code error because of ambiguity between the two
functions.
Has code breakage ever been taken into account during this dconf conversation?
I see what you mean now. You
On Saturday, 4 May 2013 at 23:44:27 UTC, Walter Bright wrote:
On 5/4/2013 4:34 PM, Walter Bright wrote:
And later down the road, maybe even in 2.064, ref will take
r-values
making the new code error because of ambiguity between the two
functions.
Has code breakage ever been taken into account
On 05/05/2013 01:30 AM, Walter Bright wrote:
On 5/4/2013 3:50 PM, deadalnix wrote:
Require isn't the right word, or you hav to explain yourself much more.
You need an explicit annotation if a ref parameter is returned by ref by
that function. This is what Rust's annotations do.
Consider:
On 5/4/2013 4:47 PM, Diggory wrote:
What about this:
void foo(ref int i);
void foo(ref const(int) i);
void main() {
int i;
foo(i);
foo(1);
}
What do they match here?
An rvalue ref is not const, so (1) would match the same as (i) does.
On 05/05/2013 01:47 AM, Diggory wrote:
On Saturday, 4 May 2013 at 23:44:27 UTC, Walter Bright wrote:
On 5/4/2013 4:34 PM, Walter Bright wrote:
And later down the road, maybe even in 2.064, ref will take r-values
making the new code error because of ambiguity between the two
functions.
Has
On Saturday, 4 May 2013 at 23:56:09 UTC, Walter Bright wrote:
On 5/4/2013 4:36 PM, deadalnix wrote:
This is good, but not I'm a bit bitter with the whole code
breakage of slice are
rvalues that happened recently.
I know that code breakage sux.
And in this case, this was avoidable. We MUST
On 5/4/2013 4:36 PM, deadalnix wrote:
This is good, but not I'm a bit bitter with the whole code breakage of slice are
rvalues that happened recently.
I know that code breakage sux.
On Saturday, 4 May 2013 at 23:30:01 UTC, Walter Bright wrote:
On 5/4/2013 3:50 PM, deadalnix wrote:
Require isn't the right word, or you hav to explain yourself
much more.
You need an explicit annotation if a ref parameter is returned
by ref by that function. This is what Rust's annotations
On 5/4/2013 4:51 PM, Timon Gehr wrote:
What is the point? Rust conservatively assumes this by default.
We could do that, too, and then disallow all code that looks like:
ref T foob(ref U u);
ref T bar() { U u; return foob(u); }
which I doubt would be very popular. Or we could
Couple amendments:
On 5/4/13 2:33 PM, Walter Bright wrote:
Case B:
ref T foob(ref U u) { return u.t; } // note that T is derivable from U
ref U bar() { T t; return foob(t); }
That's not derivable, it's embedded: type U transitively has a member of
type T.
Same case applies to
On 5/4/13 4:32 PM, Diggory wrote:
So just to be clear, ref parameters can now take rvalues?
That part of the design isn't finished yet.
Andrei
On 5/4/13 5:22 PM, deadalnix wrote:
I still think this is inferior to Rust's solution and like to see ref as
a equivalent of the Rust burrowed pointer.
http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html
Andrei
On 5/4/13 7:31 PM, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a ref parameter will automagically work with r-values?
Yes.
This is new to me. My understanding is that the discussed design
addresses safety, and leaves the rvalue
On 5/4/13 7:03 PM, Andrej Mitrovic wrote:
This resolution should be a DIP that goes through a review just like
all the other DIPs, otherwise DIPs are pointless if they get overruled
by some behind-the-scenes conversation.
Yes.
Andrei
Andrei Alexandrescu:
http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html
The management of pointers is one of the most refined parts of
the Rust design. It offers safety, allows per-thread GCs, and
more. It's powerful but it also adds some complexity to the
language.
Bye,
On 5/4/2013 5:02 PM, deadalnix wrote:
On Saturday, 4 May 2013 at 23:30:01 UTC, Walter Bright wrote:
On 5/4/2013 3:50 PM, deadalnix wrote:
Require isn't the right word, or you hav to explain yourself much more.
You need an explicit annotation if a ref parameter is returned by ref by that
On Saturday, May 04, 2013 20:37:36 Andrei Alexandrescu wrote:
On 5/4/13 7:31 PM, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a ref parameter will automagically work with r-values?
Yes.
This is new to me. My understanding is
On Sunday, May 05, 2013 01:03:17 Andrej Mitrovic wrote:
On 5/4/13, Walter Bright newshou...@digitalmars.com wrote:
Andrei I argued that we needed to make it work with just ref
annotations.
So to recap, 2.063 turns slices into r-values which will break code
that used ref, e.g.:
-
On 5/4/2013 6:44 PM, Jonathan M Davis wrote:
On Saturday, May 04, 2013 20:37:36 Andrei Alexandrescu wrote:
On 5/4/13 7:31 PM, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a ref parameter will automagically work with r-values?
Yes.
On 5/4/2013 5:42 PM, bearophile wrote:
Andrei Alexandrescu:
http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html
The management of pointers is one of the most refined parts of the Rust design.
It offers safety, allows per-thread GCs, and more. It's powerful but it also
adds some
On 5/4/13 10:04 PM, Walter Bright wrote:
That wasn't my understanding. I thought we agreed that since rvalues
would be copied to locals, and then the issue was one of escaping local
references.
The short answer is no.
Andrei
On 5/4/2013 5:28 PM, Andrei Alexandrescu wrote:
Couple amendments:
On 5/4/13 2:33 PM, Walter Bright wrote:
Case B:
ref T foob(ref U u) { return u.t; } // note that T is derivable from U
ref U bar() { T t; return foob(t); }
That's not derivable, it's embedded: type U transitively has a member
On Saturday, May 04, 2013 19:04:21 Walter Bright wrote:
On 5/4/2013 6:44 PM, Jonathan M Davis wrote:
On Saturday, May 04, 2013 20:37:36 Andrei Alexandrescu wrote:
On 5/4/13 7:31 PM, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a
On 5/4/2013 7:16 PM, Andrei Alexandrescu wrote:
On 5/4/13 10:04 PM, Walter Bright wrote:
That wasn't my understanding. I thought we agreed that since rvalues
would be copied to locals, and then the issue was one of escaping local
references.
The short answer is no.
Please explain your
On Saturday, May 04, 2013 19:07:25 Walter Bright wrote:
On 5/4/2013 5:42 PM, bearophile wrote:
Andrei Alexandrescu:
http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html
The management of pointers is one of the most refined parts of the Rust
design. It offers safety, allows
On 5/4/2013 7:30 PM, Jonathan M Davis wrote:
On Saturday, May 04, 2013 19:04:21 Walter Bright wrote:
On 5/4/2013 6:44 PM, Jonathan M Davis wrote:
On Saturday, May 04, 2013 20:37:36 Andrei Alexandrescu wrote:
On 5/4/13 7:31 PM, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all
On Saturday, May 04, 2013 20:12:24 Walter Bright wrote:
I'm not sure what you mean by nop rvalue conversions, at least not by
name.
I meant exactly what you said: and not know that it was effectively a
no-op.
Oh, okay. LOL. I was thinking you meant something lower level like than that,
On Sunday, 5 May 2013 at 02:36:45 UTC, Jonathan M Davis wrote:
Don was complaining that one reason that moving
to D2 at Sociomantic looks unappealing in spite of the benefits
is the fact
that they're going to have to add so many extra annotations to
their code.
When did he mention that? If I
On Sunday, 5 May 2013 at 02:04:14 UTC, Walter Bright wrote:
That wasn't my understanding. I thought we agreed that since
rvalues would be copied to locals, and then the issue was one
of escaping local references.
I think you, Manu and I agreed on this simplification, and thus
consequently
On Sunday, 5 May 2013 at 01:45:05 UTC, Jonathan M Davis wrote:
On Saturday, May 04, 2013 20:37:36 Andrei Alexandrescu wrote:
On 5/4/13 7:31 PM, Walter Bright wrote:
On 5/4/2013 3:51 PM, w0rp wrote:
Does all of this also mean that a
function with a ref parameter will automagically work with
On 5/4/2013 7:36 PM, Jonathan M Davis wrote:
The trick is balancing it so that it's powerful enough and yet not too
complicated to be useable by normal programmers. I think that we're okay, but
I also think that we're pushing it as it is. Going with Bartosz proposal would
almost certainly have
98 matches
Mail list logo
