On 13.11.2012 15:07, martin wrote:
On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:
Your proposal isn't really related to this thread's topic
Um, "Const ref and rvalues again", I suggest it to be the default
behavior, how is this not related ?
The topic her
On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:
Your proposal isn't really related to this thread's topic
Um, "Const ref and rvalues again", I suggest it to be the
default behavior, how is this not related ?
The topic here is binding rvalues to (const) ref
On Tuesday, 13 November 2012 at 10:09:27 UTC, luka8088 wrote:
Can you point out any existing public code that would be broken?
Off hand, no.. I'm not that familiar with a lot of the code or
the in depth details of phoboes; However suddenly reversing what
is mutable and what is const is bound
On 13.11.2012 11:00, Era Scarecrow wrote:
On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:
Would it ? How many functions actually change their non ref/out
arguments ? Can you point out any existing public code that would be
broken ?
It would be possible that if the language became
On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:
Would it ? How many functions actually change their non ref/out
arguments ? Can you point out any existing public code that
would be broken ?
It would be possible that if the language became
const-preference that a simple regex to
changed
y = 2; // ok, y is copied
z = 3; // ok, z is a reference
}
Your proposal isn't really related to this thread's topic, but I
Um, "Const ref and rvalues again", I suggest it to be the default
behavior, how is this not related ?
understand what you mean (although your co
On Monday, 12 November 2012 at 23:38:43 UTC, luka8088 wrote:
What about making this a default behavior and introducing a new
keyword if the function wants to modify the argument but it is
not ref (pass by value) ? The reason I think that this should
be a default behavior because not many functi
What about making this a default behavior and introducing a new keyword
if the function wants to modify the argument but it is not ref (pass by
value) ? The reason I think that this should be a default behavior
because not many functions actually modify their arguments and so it
leaves a lot of
On Sunday, November 11, 2012 13:30:12 Manu wrote:
> What do you mean 'aren't really references in the normal sense'?
ref is not really part of a variable's type. It's just a storage class and is
really only applicable in very specific circumstances. A function parameter is
a local variable, but
On Sunday, November 11, 2012 15:17:03 Dmitry Olshansky wrote:
> Something must be screwed up. I dunno what, I use near-latest DMD from
> github and Win32 binaries.
I'm on 64-bit Linux, so that may change things a bit.
- Jonathan M Davis
On Sunday, November 11, 2012 12:10:59 David Nadlinger wrote:
> On Sunday, 11 November 2012 at 10:09:17 UTC, Jonathan M Davis
>
> wrote:
> > It still prints "hello", even with full optimations turned on.
> > So, it must be
> > allocating a closure in spite of scope. So, it looks to me like
> > scop
On 10 November 2012 21:07, Jonathan M Davis wrote:
> On Saturday, November 10, 2012 13:21:42 Manu wrote:
> > I'm still not buying this. Here's a common struct I will pass by ref
> > (perhaps the most common struct in my industry):
> >
> > struct Vector { float, x,y,z,w; }
> > struct Matrix { Vect
11/11/2012 2:08 PM, Jonathan M Davis пишет:
On Sunday, November 11, 2012 13:36:05 Dmitry Olshansky wrote:
Nope. It's just that the stack is intact and contains: hello and goodbye
one after another. Without optimizations { } scope doesn't mean reuse
stack space.
Now if play with stack a bit, for
On Sunday, 11 November 2012 at 10:09:17 UTC, Jonathan M Davis
wrote:
It still prints "hello", even with full optimations turned on.
So, it must be
allocating a closure in spite of scope. So, it looks to me like
scope is just
completely ignored and does absolutely nothing at this point,
unless I
On Sunday, November 11, 2012 13:36:05 Dmitry Olshansky wrote:
> Nope. It's just that the stack is intact and contains: hello and goodbye
> one after another. Without optimizations { } scope doesn't mean reuse
> stack space.
>
> Now if play with stack a bit, for me the next one prints:
> -²↑
>
>
11/10/2012 11:07 PM, Jonathan M Davis пишет:
And actually, to make matters worse, I'm not sure that scope on delegates is
working correctly. I thought that it was, but this code compiles:
import std.stdio;
void delegate() global;
void foo(scope void delegate() del)
{
global = del;
}
void
On Saturday, November 10, 2012 13:21:42 Manu wrote:
> I'm still not buying this. Here's a common struct I will pass by ref
> (perhaps the most common struct in my industry):
>
> struct Vector { float, x,y,z,w; }
> struct Matrix { Vector xRow, yRow, zRow, wRow; }
>
> Vector mul( scope const ref Ma
On 9 November 2012 21:39, Jonathan M Davis wrote:
> On Friday, November 09, 2012 15:55:12 Manu wrote:
> > Does that actually make sense? Surely a function that receives a scope
> > argument can return that argument, since it's only passing it back to the
> > same function that already owns it...
On Friday, November 09, 2012 15:55:12 Manu wrote:
> Does that actually make sense? Surely a function that receives a scope
> argument can return that argument, since it's only passing it back to the
> same function that already owns it... it knows it can trust that function,
> since it was received
On Friday, 9 November 2012 at 16:53:01 UTC, Regan Heath wrote:
Nice detailed proposal. I would suggest starting a new thread
with it, to catch anyone who dozed off in this thread :p
Thanks, and you're probably right. Here's the link:
http://forum.dlang.org/thread/zteryxwxyngvyqvuk...@forum.dl
On Fri, 09 Nov 2012 16:26:21 -, martin wrote:
Let me summarize my (final, I guess) proposal. I think it makes sense to
compare it to C++ in order to anticipate and hopefully invalidate
(mainly Andrei's) objections.
parameter type | lvalue|rvalue
Let me summarize my (final, I guess) proposal. I think it makes
sense to compare it to C++ in order to anticipate and hopefully
invalidate (mainly Andrei's) objections.
parameter type | lvalue|rvalue
| C++ D | C++ D
|-
On 9 November 2012 10:46, Jonathan M Davis wrote:
> On Friday, November 09, 2012 10:33:45 Manu wrote:
> > On 9 November 2012 00:44, Jonathan M Davis wrote:
> > > On Thursday, November 08, 2012 21:49:58 Manu wrote:
> > > > That's cute, but it really feels like a hack.
> > > > All of a sudden the
On Friday, November 09, 2012 10:33:45 Manu wrote:
> On 9 November 2012 00:44, Jonathan M Davis wrote:
> > On Thursday, November 08, 2012 21:49:58 Manu wrote:
> > > That's cute, but it really feels like a hack.
> > > All of a sudden the debugger doesn't work properly anymore, you need to
> > > step
On 9 November 2012 00:44, Jonathan M Davis wrote:
> On Thursday, November 08, 2012 21:49:58 Manu wrote:
> > That's cute, but it really feels like a hack.
> > All of a sudden the debugger doesn't work properly anymore, you need to
> > step-in twice to enter the function, and it's particularly inef
On Thursday, 8 November 2012 at 22:44:26 UTC, Jonathan M Davis
wrote:
I honestly wish that in didn't exist in the language. The fact
that it it's an alias two different attributes is confusing, and
people keep using it without realizing what they're getting
into.
If scope worked correctly, you'
On Thursday, 8 November 2012 at 22:34:03 UTC, Timon Gehr wrote:
Ambiguous to me and all the interpretations are either wrong or
irrelevant.
My point is that it may affect performance. If there was no
const, the compiler would need to allocate a dedicated copy of a
literal whenever passing it
On Thursday, November 08, 2012 21:49:58 Manu wrote:
> That's cute, but it really feels like a hack.
> All of a sudden the debugger doesn't work properly anymore, you need to
> step-in twice to enter the function, and it's particularly inefficient in
> debug builds (a point of great concern for my i
On 11/08/2012 02:45 AM, martin wrote:
On Wednesday, 7 November 2012 at 21:39:52 UTC, Timon Gehr wrote:
You can pass him an object that does not support operations you want
to preclude. He does not have to _know_, that your book is not changed
when he reads it. This is an implementation detail. I
On Thursday, 8 November 2012 at 20:15:51 UTC, Dmitry Olshansky
wrote:
The scope. It's all about getting the correct scope, destructor
call and you know, the works. Preferably it can inject it
inside temporary scope.
typeof(foo(...)) r = void;
{
someRef = SomeResource(x, y, ..);
r = foo(someRef
11/8/2012 11:30 PM, martin пишет:
On Thursday, 8 November 2012 at 18:28:44 UTC, Dmitry Olshansky wrote:
What's wrong with going this route:
void blah(auto ref X stuff){
...lots of code...
}
is magically expanded to:
void blah(ref X stuff){
...that code..
}
and
void blah(X stuff){
.blah(
That's cute, but it really feels like a hack.
All of a sudden the debugger doesn't work properly anymore, you need to
step-in twice to enter the function, and it's particularly inefficient in
debug builds (a point of great concern for my industry!).
Please just with the compiler creating a tempora
On Thursday, 8 November 2012 at 18:28:44 UTC, Dmitry Olshansky
wrote:
What's wrong with going this route:
void blah(auto ref X stuff){
...lots of code...
}
is magically expanded to:
void blah(ref X stuff){
...that code..
}
and
void blah(X stuff){
.blah(stuff); //now here stuff is L-value so
11/7/2012 9:04 PM, martin пишет:
On Wednesday, 7 November 2012 at 14:07:31 UTC, martin wrote:
C++:
void f(T& a) { // for lvalues
this->resource = a.resource;
a.resetResource();
}
void f(T&& a) { // for rvalues (moved)
this->resource = a.resource;
a.resetResource();
}
D:
void f(r
11/7/2012 3:54 AM, Manu пишет:
If the compiler started generating 2 copies of all my ref functions, I'd
be rather unimpressed... bloat is already a problem in D. Perhaps this
may be a handy feature, but I wouldn't call this a 'solution' to this issue.
Also, what if the function is external (likel
On Thursday, 8 November 2012 at 03:07:00 UTC, Jonathan M Davis
wrote:
Okay. Here are more links to Andrei discussing the problem:
http://forum.dlang.org/post/4f83dbe5.20...@erdani.com
http://www.mail-archive.com/digitalmars-d@puremagic.com/msg44070.html
http://www.mail-archive.com/digitalmars-d@
On Thursday, October 18, 2012 05:07:52 Malte Skarupke wrote:
> What do you think?
Okay. Here are more links to Andrei discussing the problem:
http://forum.dlang.org/post/4f83dbe5.20...@erdani.com
http://www.mail-archive.com/digitalmars-d@puremagic.com/msg44070.html
http://www.mail-archive.com/dig
On Wednesday, 7 November 2012 at 21:39:52 UTC, Timon Gehr wrote:
You can pass him an object that does not support operations you
want to preclude. He does not have to _know_, that your book is
not changed when he reads it. This is an implementation detail.
In fact, you could make the book save
On 11/07/2012 07:48 PM, martin wrote:
On Wednesday, 7 November 2012 at 18:07:27 UTC, Timon Gehr wrote:
You do not give a justification.
I find it very useful to know that an argument
won't be modified.
That is unrelated and does not necessarily follow, but that it does in
some cases is the m
On Wednesday, 7 November 2012 at 14:07:31 UTC, martin wrote:
T g() {
T temp;
temp.createResource();
return temp; // D already moves temp!
// 'Named Return Value Optimization'
}
OK, it seems to be working as you describe.
The main question I have is if I can rely o
On Wednesday, 7 November 2012 at 18:07:27 UTC, Timon Gehr wrote:
You do not give a justification.
I find it very useful to know that an argument
won't be modified.
That is unrelated and does not necessarily follow, but that it
does in some cases is the main reason why const is useful even
t
On 11/07/2012 06:52 PM, martin wrote:
On Wednesday, 7 November 2012 at 16:57:47 UTC, Timon Gehr wrote:
That is the main thing, but C++ also has a 'mutable' keyword.
Right, I forgot this inconspicuous little keyword. It really is a huge
hole in C++'s const system.
If your struct doesn't suppo
On Wednesday, 7 November 2012 at 16:57:47 UTC, Timon Gehr wrote:
That is the main thing, but C++ also has a 'mutable' keyword.
Right, I forgot this inconspicuous little keyword. It really is a
huge hole in C++'s const system.
If your struct doesn't support any const operations, it most
like
On Wednesday, 7 November 2012 at 14:07:31 UTC, martin wrote:
C++:
void f(T& a) { // for lvalues
this->resource = a.resource;
a.resetResource();
}
void f(T&& a) { // for rvalues (moved)
this->resource = a.resource;
a.resetResource();
}
D:
void f(ref T a) { // for lvalues
this.
On 11/07/2012 04:01 PM, martin wrote:
On Wednesday, 7 November 2012 at 10:33:03 UTC, Timon Gehr wrote:
You are still missing that const in C++ is different from const in D.
const in C++ does not mean anything. It is just loosely enforced
interface documentation. const in D actually restricts wha
On Wednesday, 7 November 2012 at 10:33:03 UTC, Timon Gehr wrote:
You are still missing that const in C++ is different from const
in D.
const in C++ does not mean anything. It is just loosely
enforced interface documentation. const in D actually restricts
what the callee can do with the argument
On Wednesday, 7 November 2012 at 06:13:25 UTC, Rob T wrote:
ref T works fine, but if you wish to use f( ref T a ) on a temp
value returned from another function call, you'll need to
overload f() to pass by value, which means creating a duplicate.
Duplicating the function, yes, but not duplicat
On Wednesday, 7 November 2012 at 10:33:03 UTC, Timon Gehr wrote:
You are still missing that const in C++ is different from const
in D. Also, if the point is to have higher speed, why shouldn't
the function be allowed to use an rvalue as scratch space
without a _deep copy_ ?
const in C++ does
On 11/07/2012 04:13 AM, martin wrote:
On Wednesday, 7 November 2012 at 02:58:57 UTC, Era Scarecrow wrote:
Maybe a very simple change/addition; Like perhaps @ref? (Attribute
ref, Alternate ref, auto ref.. All sorta fit for it's meaning).
So...
void func1(ref int x); //D lvalue-only ref
void fu
On Wednesday, 7 November 2012 at 02:34:25 UTC, martin wrote:
On Wednesday, 7 November 2012 at 02:06:09 UTC, Rob T wrote:
What about the case where we want to pass a source argument
either by reference or as a copy depending on the l/r value
situation?
eg
void f( ref a );
void f( a );
--rt
On Wednesday, 7 November 2012 at 04:36:59 UTC, Era Scarecrow
wrote:
Maybe... But when working with non built-in types can you
guarantee that behavior?
Sure, try it out.
What you are referring to here has nothing to do with rvalues. It
is about side results which are only sometimes needed. It
On Wednesday, 7 November 2012 at 04:05:32 UTC, martin wrote:
int func(in ref int x);
int func(int x) { return func(x); }
The latter overload is for rvalues (no need to cast to const)
and wouldn't be required if the first one took rvalues directly
(having a _const_ ref parameter). That's not an
On Wednesday, 7 November 2012 at 03:35:19 UTC, Era Scarecrow
wrote:
Still that zlib entry is coming to mind. But more importantly
is that you still need code duplication to get both accessible.
//many possible combinations thereof
int func(const ref x);
int func(int x) {
return func(cast(cons
On Wednesday, 7 November 2012 at 03:13:22 UTC, martin wrote:
void func1(ref int x); //D lvalue-only ref
void func2(@ref int x); //works like c++'s ref
Seems fairly easy to tell apart, and still leaves const-ness
as an option.
Afaik C++ doesn't allow rvalues to be passed to _mutable_
referen
On Wednesday, 7 November 2012 at 03:13:22 UTC, martin wrote:
void func1(ref int x); //D lvalue-only ref
void func2(@ref int x); //works like c++'s ref
Seems fairly easy to tell apart, and still leaves const-ness
as an option.
Afaik C++ doesn't allow rvalues to be passed to _mutable_
referen
On Wednesday, 7 November 2012 at 02:58:57 UTC, Era Scarecrow
wrote:
Maybe a very simple change/addition; Like perhaps @ref?
(Attribute ref, Alternate ref, auto ref.. All sorta fit for
it's meaning).
So...
void func1(ref int x); //D lvalue-only ref
void func2(@ref int x); //works like c++'s r
On Wednesday, 7 November 2012 at 02:45:15 UTC, martin wrote:
Please discard option 1, I'm afraid it creates too much
confusion and was not well thought through. The objective was
to expand 'auto ref T' to either 'in ref T' for lvalues or 'in
T' for rvalues (I.e., only for const parameters!), bu
On Tuesday, 6 November 2012 at 23:37:25 UTC, martin wrote:
1) The previously described auto-templates (identical 'auto
ref' semantics), where a function with 'auto ref' parameters is
treated as implicit template. This may lead to code-bloating
(for larger functions) and/or higher performance fo
On Wednesday, 7 November 2012 at 02:06:09 UTC, Rob T wrote:
What about the case where we want to pass a source argument
either by reference or as a copy depending on the l/r value
situation?
eg
void f( ref a );
void f( a );
--rt
I don't get what you mean - that's why the 2 overloads are for
On Wednesday, 7 November 2012 at 01:33:49 UTC, Jonathan M Davis
wrote:
The most recent discussion where Walter and Andrei were part of
the discussion
was here:
http://forum.dlang.org/post/4f84d6dd.5090...@digitalmars.com
That thread is quite misleading and, I'm sad to say, not very
useful (r
On Tuesday, 6 November 2012 at 23:37:25 UTC, martin wrote:
void func(T)(in auto ref T m);
This template, as I understand it, gets expanded to:
void func(T)(in ref T m); // for lvalues
void func(T)(in T m); // for rvalues
So for non-templated functions, I suggest 2 options:
1) The previou
On Wednesday, 7 November 2012 at 01:15:27 UTC, martin wrote:
I simply and utterly fail to comprehend the need for a compiler
to distinguish between a const reference to a named variable
and a const reference to an unnamed temporary/literal (which
the compiler is free to allocate wherever it mak
On Wednesday, 7 November 2012 at 00:32:04 UTC, martin wrote:
So we do not really need 'auto ref' for non-templated functions
or a new, even more confusing keyword which you, Jonathan, seem
to insist on - 'const ref' (or, more elegantly 'in ref') is all
we need. We simply want the compiler to au
On Wednesday, November 07, 2012 02:15:26 martin wrote:
> Wow, now this finally sheds some light on this topic. Do you have
> any links regarding their reasoning?
The most recent discussion where Walter and Andrei were part of the discussion
was here:
http://forum.dlang.org/post/4f84d6dd.5090...@
On Wednesday, 7 November 2012 at 00:47:04 UTC, Jonathan M Davis
wrote:
No, because that would be doing the same thing as C++, which
Walter and Andrei
have already rejected. They specifically do _not_ want there to
be any
ambiguity between whether a const ref variable is an lvalue or
rvalue. If
On Wednesday, November 07, 2012 01:32:03 martin wrote:
> So we do not really need 'auto ref' for non-templated functions
> or a new, even more confusing keyword which you, Jonathan, seem
> to insist on - 'const ref' (or, more elegantly 'in ref') is all
> we need.
No, because that would be doing th
Thanks Jonathan for the detailed info. So 'auto ref' is
implemented the way I thought, by simply duplicating functions.
That is actually the only way (I can think of) to solve your
problem 'pass this argument in the most efficient way possible
(do not copy)'.
But that is not the only problem.
If the compiler started generating 2 copies of all my ref functions, I'd be
rather unimpressed... bloat is already a problem in D. Perhaps this may be
a handy feature, but I wouldn't call this a 'solution' to this issue.
Also, what if the function is external (likely)... auto ref can't work if
the
On Wednesday, November 07, 2012 00:32:48 Manu wrote:
> But it only really makes sense in the context of templates...?
> Why should something called 'auto ref' provide fabrication of temporaries
> for the purpose of passing rvalues to functions that receive ref args?
>
> How does auto ref (under so
On Tuesday, 6 November 2012 at 22:32:57 UTC, Manu wrote:
But it only really makes sense in the context of templates...?
Why should something called 'auto ref' provide fabrication of
temporaries
for the purpose of passing rvalues to functions that receive
ref args?
How does auto ref (under som
But it only really makes sense in the context of templates...?
Why should something called 'auto ref' provide fabrication of temporaries
for the purpose of passing rvalues to functions that receive ref args?
How does auto ref (under some different definition/implementation) address
the rvalue prob
On Tuesday, November 06, 2012 20:40:38 Manu wrote:
> Yeah I really don't understand how 'auto ref' entered this conversation? It
> completely misses the point.
The _entire_ reason that auto ref was introduced in the first place was to
solve the const ref problem. That's what it's for. It wouldn't
Yeah I really don't understand how 'auto ref' entered this conversation? It
completely misses the point.
The issue as I see it is this:
void func(ref in Vector m);
func(v1*v2 + Vector(10, 20, 30));
And countless situations like it, all leading to innumerable temp locals
with irrelevant names:
On Monday, 5 November 2012 at 08:01:57 UTC, Jonathan M Davis
wrote:
auto ref's current semantics can't possibly work with
non-templated functions,
and it's clear that there are good reasons for keeping auto ref
as it is now
for templates. So, either we make it work with non-templated
functions
On Monday, November 05, 2012 06:05:07 Rob T wrote:
> On Monday, 5 November 2012 at 03:26:10 UTC, Jonathan M Davis
>
> wrote:
> > And when we argued for altering it so that it operated like
> > const ref in C++
> > (which allows const ref in D to continue to function like it
> > does now), some
> >
On Monday, 5 November 2012 at 03:26:10 UTC, Jonathan M Davis
wrote:
And when we argued for altering it so that it operated like
const ref in C++
(which allows const ref in D to continue to function like it
does now), some
folks complained, because they've found the current semantics
of auto ref
On Monday, 5 November 2012 at 03:26:10 UTC, Jonathan M Davis
wrote:
On Sunday, November 04, 2012 20:43:36 Andrei Alexandrescu wrote:
On 11/4/12 7:58 PM, martin wrote:
> I find it sad that while this topic seems to be of high
> priority for
> quite a lot of language users, it is seemingly neglec
On Sunday, November 04, 2012 20:43:36 Andrei Alexandrescu wrote:
> On 11/4/12 7:58 PM, martin wrote:
> > I find it sad that while this topic seems to be of high priority for
> > quite a lot of language users, it is seemingly neglected by the head of
> > language development (Walter, Andrei etc.).
>
On 11/4/12 7:58 PM, martin wrote:
I find it sad that while this topic seems to be of high priority for
quite a lot of language users, it is seemingly neglected by the head of
language development (Walter, Andrei etc.).
I was hoping "auto ref" solves this problem. I think it's currently only
im
On Monday, 5 November 2012 at 00:58:19 UTC, martin wrote:
I find it sad that while this topic seems to be of high
priority for quite a lot of language users, it is seemingly
neglected by the head of language development (Walter, Andrei
etc.).
I don't know why this would be ignored, it's rathe
I find it sad that while this topic seems to be of high priority
for quite a lot of language users, it is seemingly neglected by
the head of language development (Walter, Andrei etc.).
On Thursday, 18 October 2012 at 03:07:56 UTC, Malte Skarupke
wrote:
Hello,
I realize that this has been discussed before, but so far there
is no solution and this really needs to be a high priority:
We need a way for a function to declare that it doesn't want
it's argument to be copied, but
On Monday, 22 October 2012 at 11:59:27 UTC, martin wrote:
In the latter overload for rvalues, you aren't given the
original rvalue, but a copy of it!
I need to correct that after a quick test: the rvalue is passed
directly (moved) instead of copying it (well, at least the copy
constructor thi
On Monday, 22 October 2012 at 09:41:38 UTC, Timon Gehr wrote:
(But it might be added that C++11 adds a new language feature
just in order to be able to distinguish const and rvalue
references in the callee, so even with C++'s semantics, this
does not seem like a good idea.)
Yeah, and that T&& s
On 10/22/2012 11:38 AM, Timon Gehr wrote:
On 10/22/2012 12:18 AM, martin wrote:
On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote:
Const is different in D and in C++. Relating const and rvalues is
arbitrary and does not make a lot of sense.
It's actually pretty much the same concep
On 10/22/2012 12:18 AM, martin wrote:
On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote:
Const is different in D and in C++. Relating const and rvalues is
arbitrary and does not make a lot of sense.
It's actually pretty much the same concept in both languages except for
the transiti
On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote:
Const is different in D and in C++. Relating const and rvalues
is arbitrary and does not make a lot of sense.
It's actually pretty much the same concept in both languages
except for the transitiveness in D. An implicit rvalue => _co
On 10/20/2012 08:25 PM, Malte Skarupke wrote:
...
So it comes down to this:
void goo(scope int* x)
{
global0 = x; // copying is allowed
//global1 = &x; // referencing is not allowed
}
That is useless.
On Friday, 19 October 2012 at 13:00:52 UTC, Timon Gehr wrote:
On 10/19/2012 09:53 AM, Jacob Carlborg wrote:
On 2012-10-19 04:48, Timon Gehr wrote:
Then how to specify that the value of x cannot be escaped?
I'm in favour of doing it the other way round and disallow
escaping of
ref parameters
On 10/19/2012 09:53 AM, Jacob Carlborg wrote:
On 2012-10-19 04:48, Timon Gehr wrote:
Then how to specify that the value of x cannot be escaped?
I'm in favour of doing it the other way round and disallow escaping of
ref parameters without an unsafe cast.
"scope" is supposed to be used to preve
On Friday, 19 October 2012 at 07:53:30 UTC, Jacob Carlborg wrote:
On 2012-10-19 04:48, Timon Gehr wrote:
Then how to specify that the value of x cannot be escaped?
I'm in favour of doing it the other way round and disallow
escaping of
ref parameters without an unsafe cast.
"scope" is suppos
On 2012-10-19 04:48, Timon Gehr wrote:
Then how to specify that the value of x cannot be escaped?
I'm in favour of doing it the other way round and disallow escaping of
ref parameters without an unsafe cast.
"scope" is supposed to be used to prevent this.
--
/Jacob Carlborg
@jerro: the same thing: I'm not trying to fix the problem that
you mention. I'm trying to define a function which can safely
accept rvalues and lvalues without having to make a copy.
My point was that saving an address of a const ref parameter is
already unsafe if you call the function with a
On 10/19/2012 03:26 AM, Malte Skarupke wrote:
On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote:
Const is different in D and in C++. Relating const and rvalues is
arbitrary and does not make a lot of sense.
Regarding 'in ref'/'scope ref': What should 'scope' apply to in
void foo(sc
On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote:
Const is different in D and in C++. Relating const and rvalues
is arbitrary and does not make a lot of sense.
Regarding 'in ref'/'scope ref': What should 'scope' apply to in
void foo(scope ref int* x);
Not sure what you mean wit
On 10/19/2012 01:39 AM, Malte Skarupke wrote:
On Thursday, 18 October 2012 at 06:11:26 UTC, monarch_dodra wrote:
On Thursday, 18 October 2012 at 04:30:17 UTC, Jonathan M Davis wrote:
On Thursday, October 18, 2012 06:24:08 jerro wrote:
What would be the problem with const ref taking rvalues?
The problem with binding rvalues to const ref is that you could
take and store the address of it. That's why I'd recommend
using "in ref" instead.
You can also take and store the address of a local variable that
was passed as a const ref parameter, and accessing it after the
caller exits will
On Thursday, 18 October 2012 at 06:11:26 UTC, monarch_dodra wrote:
On Thursday, 18 October 2012 at 04:30:17 UTC, Jonathan M Davis
wrote:
On Thursday, October 18, 2012 06:24:08 jerro wrote:
What would be the problem with const ref taking rvalues?
Read the thread that I already linked to:
http
On Thursday, 18 October 2012 at 06:11:26 UTC, monarch_dodra wrote:
On Thursday, 18 October 2012 at 04:30:17 UTC, Jonathan M Davis
wrote:
On Thursday, October 18, 2012 06:24:08 jerro wrote:
What would be the problem with const ref taking rvalues?
Read the thread that I already linked to:
http
On Thursday, 18 October 2012 at 04:30:17 UTC, Jonathan M Davis
wrote:
On Thursday, October 18, 2012 06:24:08 jerro wrote:
What would be the problem with const ref taking rvalues?
Read the thread that I already linked to:
http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com
- Jonath
1 - 100 of 119 matches
Mail list logo
