Am Wed, 19 Oct 2016 11:29:50 +0200
schrieb Timon Gehr :
> Yes, the lack of rvalue references can be annoying but 'const' should be
> orthogonal to any implemented solution.
>
> There should be a way to pass rvalues by reference that are not
> prevented from being mutated, and it should be the s
On 19.10.2016 04:58, Marco Leise wrote:
Am Tue, 18 Oct 2016 22:43:01 +0200
schrieb Timon Gehr :
It wouldn't even be the same thing if it was allowed. D const is not C++
const. Enforcing transitive read-only on rvalue references does not make
that much sense.
For me using const ref vs. const i
Am Tue, 18 Oct 2016 22:43:01 +0200
schrieb Timon Gehr :
> It wouldn't even be the same thing if it was allowed. D const is not C++
> const. Enforcing transitive read-only on rvalue references does not make
> that much sense.
For me using const ref vs. const is typically entirely a
matter of avo
On Friday, 12 June 2015 at 19:39:25 UTC, Stewart Gordon wrote:
On 09/06/2015 13:14, Namespace wrote:
What does this have to do with "garbage-collected language"?
If I have a big struct, e.g.
struct Matrix {
float[16] values = [...];
}
I always want to pass it by ref because a mov
On 09/06/2015 13:14, Namespace wrote:
What does this have to do with "garbage-collected language"?
If I have a big struct, e.g.
struct Matrix {
float[16] values = [...];
}
I always want to pass it by ref because a move or a copy would be too slow.
That seems to me a matter more
On Wed, 10 Jun 2015 04:52:46 -0400, kink wrote:
I know what `in` currently means. Your proposed `in ref T` syntax is imo
not much better than C++ `const T&`, so I'd prefer a simple and
convenient `in T`. Semantics would be identical to your `in ref` with
the additional optimization for sma
On Tuesday, 9 June 2015 at 20:25:28 UTC, Namespace wrote:
No opinions on the semantics for `in` I proposed earlier? `in
T` would be something like a non-escapable `const auto ref T`
accepting rvalues without codebloat and avoiding the
indirection for small POD types T. Wouldn't that eliminate 9
No opinions on the semantics for `in` I proposed earlier? `in
T` would be something like a non-escapable `const auto ref T`
accepting rvalues without codebloat and avoiding the
indirection for small POD types T. Wouldn't that eliminate 99%
of the use cases for `auto ref`, improve readability
s
On Tuesday, 9 June 2015 at 17:38:00 UTC, Steven Schveighoffer
wrote:
But passing a large rvalue by value does not involve any moving
of data, and can be abstracted to a pass by ref if needed. It's
never less performing than an explicit pass by ref.
Thanks Steve.
The problem I see here on Win6
On 6/9/15 12:23 PM, kink wrote:
On Tuesday, 9 June 2015 at 15:08:07 UTC, Steven Schveighoffer wrote:
Because it's not moved. It's written in the stack where it will be
passed to the next function.
Hmm, you mean the callee's function parameters stack? That's not always
going to work, e.g., on W
On Tuesday, 9 June 2015 at 15:08:07 UTC, Steven Schveighoffer
wrote:
Because it's not moved. It's written in the stack where it will
be passed to the next function.
Hmm, you mean the callee's function parameters stack? That's not
always going to work, e.g., on Win64 the first 4 args are passed
On 6/9/15 10:53 AM, kink wrote:
On Tuesday, 9 June 2015 at 13:13:53 UTC, Steven Schveighoffer wrote:
It's actually faster to pass an rvalue by value, because it's
constructed on the stack anyway.
I seriously doubt that's true for a large struct, e.g., something
containing a large static array.
On Tuesday, 9 June 2015 at 13:13:53 UTC, Steven Schveighoffer
wrote:
It's actually faster to pass an rvalue by value, because it's
constructed on the stack anyway.
I seriously doubt that's true for a large struct, e.g., something
containing a large static array. Why move/copy the damn thing if
On Tue, 09 Jun 2015 07:04:36 -0400, Stewart Gordon
wrote:
To me, it sounds like people want this feature for D purely because C++
has it.
Stewart.
That's actually not a bad reason ;)
Suppose we wanted to write bindings for some C++ code which made use of
const-ref parameters:
http://he
On Tue, 09 Jun 2015 07:04:36 -0400, Stewart Gordon
wrote:
Apologies if I've missed something - I haven't had much time to keep up
with the discussions lately.
What is the use case for rvalue references in a garbage-collected
language?
To me, it sounds like people want this feature for
On Tue, 09 Jun 2015 08:26:46 -0400, kink wrote:
On Monday, 8 June 2015 at 20:16:13 UTC, bitwise wrote:
static Mat4 transform()(const auto ref Vec3 pos, const auto ref Vec3
scale, const auto ref Quat rot);
Horrific.
static Mat4 transform(in Vec3 pos, in Vec3 scale, in Quat rot);
would be s
On 6/9/15 8:14 AM, Namespace wrote:
On Tuesday, 9 June 2015 at 11:04:43 UTC, Stewart Gordon wrote:
Apologies if I've missed something - I haven't had much time to keep
up with the discussions lately.
What is the use case for rvalue references in a garbage-collected
language?
To me, it sounds l
On Monday, 8 June 2015 at 20:16:13 UTC, bitwise wrote:
static Mat4 transform()(const auto ref Vec3 pos, const auto ref
Vec3 scale, const auto ref Quat rot);
Horrific.
static Mat4 transform(in Vec3 pos, in Vec3 scale, in Quat rot);
would be so much better...
On Tuesday, 9 June 2015 at 11:04:43 UTC, Stewart Gordon wrote:
Apologies if I've missed something - I haven't had much time to
keep up with the discussions lately.
What is the use case for rvalue references in a
garbage-collected language?
To me, it sounds like people want this feature for D
Apologies if I've missed something - I haven't had much time to keep up with the
discussions lately.
What is the use case for rvalue references in a garbage-collected language?
To me, it sounds like people want this feature for D purely because C++ has it.
Stewart.
--
My email address is vali
On Monday, 8 June 2015 at 22:58:15 UTC, bitwise wrote:
On Mon, 08 Jun 2015 16:17:33 -0400, Namespace
wrote:
Yes, the same goes for Dgame.
closed-source projects can also accept rvalue-refs now ;)
Bit
Dgame is not closed-source. ;)
On Mon, 08 Jun 2015 22:16:27 -0400, Manu via Digitalmars-d
wrote:
On 9 June 2015 at 08:58, bitwise via Digitalmars-d
wrote:
On Mon, 08 Jun 2015 16:17:33 -0400, Namespace
wrote:
Yes, the same goes for Dgame.
closed-source projects can also accept rvalue-refs now ;)
How?
I mean th
On 9 June 2015 at 08:58, bitwise via Digitalmars-d
wrote:
> On Mon, 08 Jun 2015 16:17:33 -0400, Namespace wrote:
>
>> Yes, the same goes for Dgame.
>
>
> closed-source projects can also accept rvalue-refs now ;)
How?
On Mon, 08 Jun 2015 16:17:33 -0400, Namespace wrote:
Yes, the same goes for Dgame.
closed-source projects can also accept rvalue-refs now ;)
Bit
On Mon, 08 Jun 2015 11:29:56 -0400, bitwise wrote:
On Mon, 08 Jun 2015 02:44:46 -0400, Namespace wrote:
On Sunday, 7 June 2015 at 18:40:42 UTC, bitwise wrote:
On Sat, 06 Jun 2015 14:05:54 -0400, Namespace
wrote:
Finally all green! Now we need a review.
You're my hero.
Bit
Sounds
One useful case for me:
static Mat4 transform()(const auto ref Vec3 pos, const auto ref
Vec3 scale, const auto ref Quat rot)
{
Mat4 m = Mat4(rot.matrix, 1);
m.m00 *= scale.x;
m.m01 *= scale.x;
m.m02 *= scale.x;
m.m10 *= scale.y;
m.m11 *= scale.y;
m.m12 *= scale.y;
On Mon, 08 Jun 2015 02:44:46 -0400, Namespace wrote:
On Sunday, 7 June 2015 at 18:40:42 UTC, bitwise wrote:
On Sat, 06 Jun 2015 14:05:54 -0400, Namespace
wrote:
Finally all green! Now we need a review.
You're my hero.
Bit
Sounds ironic. o.O
Ironic or Sarcastic?
Neither.
Bit
On Sunday, 7 June 2015 at 18:40:42 UTC, bitwise wrote:
On Sat, 06 Jun 2015 14:05:54 -0400, Namespace
wrote:
Finally all green! Now we need a review.
You're my hero.
Bit
Sounds ironic. o.O
On Sat, 06 Jun 2015 14:05:54 -0400, Namespace wrote:
Finally all green! Now we need a review.
You're my hero.
Bit
Finally all green! Now we need a review.
On Wednesday, 3 June 2015 at 01:57:21 UTC, bitwise wrote:
'in' is currently useless because scope is not defined
properly, and const is too restrictive. Also, because of DIP25,
it's now even more useless. It seems a pretty sure bet that it
will either continue to be completely useless or be cha
On Friday, 5 June 2015 at 21:31:22 UTC, Namespace wrote:
I start working on a Pull
(https://github.com/D-Programming-Language/dmd/pull/4717), but
it fails the first check. The reason seems to be this:
https://github.com/D-Programming-Language/dmd/pull/4717/files#diff-ffafa03255a57832dd09031af6c
I start working on a Pull
(https://github.com/D-Programming-Language/dmd/pull/4717), but it
fails the first check. The reason seems to be this:
https://github.com/D-Programming-Language/dmd/pull/4717/files#diff-ffafa03255a57832dd09031af6cb915dR5945
I guess that this error happens because I canno
On Wed, 03 Jun 2015 03:09:06 -0400, Namespace wrote:
On Wednesday, 3 June 2015 at 03:57:38 UTC, bitwise wrote:
I forgot to mention, in terms of this statement I made:
I can't remember right now what the reasoning was for 'const ref' not
to take
rvalues in the first place. I think it was tha
On 06/02/2015 11:21 PM, Andrei Alexandrescu wrote:
Yah, auto ref for templates is great. We only need to add auto ref for
non-templates with the semantics "like ref, except (a) accepts rvalues
on the caller side, (b) does not allow escaping the ref from the function".
What if one wants thos
On 06/03/2015 05:43 AM, bitwise wrote:
Why can't const ref accept rvalues?
const being too restrictive doesn't seem like a real reason, because
although its undesirable for some cases, doesn't mean it can't be useful
in a _lot_ of other cases.
Its a real reason unless you endorse patchwork
On Wednesday, 3 June 2015 at 10:07:41 UTC, Marc Schütz wrote
I don't see an argument against `scope ref` in DIP36, quite the
opposite...
I know I was one of the authors. But it was rejected.
On Wednesday, 3 June 2015 at 09:53:36 UTC, Namespace wrote:
This code needs to be disallowed under DIP25 (or whatever the
final DIP will be), of course.
But should work with return ref instead.
It can even be allowed with an extension to DIP25:
struct Sprite {
private Texture* _tex;
On Tuesday, 2 June 2015 at 18:06:32 UTC, Namespace wrote:
On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), but ther
On Tuesday, 2 June 2015 at 17:31:56 UTC, Jonathan M Davis wrote:
On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), b
This code needs to be disallowed under DIP25 (or whatever the
final DIP will be), of course.
But should work with return ref instead.
On Wednesday, 3 June 2015 at 07:09:09 UTC, Namespace wrote:
On Wednesday, 3 June 2015 at 03:57:38 UTC, bitwise wrote:
I forgot to mention, in terms of this statement I made:
I can't remember right now what the reasoning was for 'const
ref' not to take
rvalues in the first place. I think it was
On Wednesday, 3 June 2015 at 03:57:38 UTC, bitwise wrote:
I forgot to mention, in terms of this statement I made:
I can't remember right now what the reasoning was for 'const
ref' not to take
rvalues in the first place. I think it was that you could
escape the reference,
but this isn't true a
On Wednesday, 3 June 2015 at 03:43:09 UTC, bitwise wrote:
I can't remember right now what the reasoning was for 'const
ref' not to take
rvalues in the first place. I think it was that you could
escape the reference,
but this isn't true anymore with DIP25 right?
The one to ask is Andrei. I can
I forgot to mention, in terms of this statement I made:
I can't remember right now what the reasoning was for 'const ref' not to
take
rvalues in the first place. I think it was that you could escape the
reference,
but this isn't true anymore with DIP25 right?
I think someone brought this u
On Tue, 02 Jun 2015 23:23:00 -0400, Jonathan M Davis
wrote:
On Wednesday, 3 June 2015 at 03:20:48 UTC, bitwise wrote:
Anyways, moving forward with the assumption that the meaning of 'in'
will
not change, I still don't understand. Why couldn't 'in ref' be allowed
to
accept rvalues in addi
On Wednesday, 3 June 2015 at 03:20:48 UTC, bitwise wrote:
Anyways, moving forward with the assumption that the meaning of
'in' will
not change, I still don't understand. Why couldn't 'in ref' be
allowed to
accept rvalues in addition to 'auto ref'?
For the same reasons that we can't have const
On Tue, 02 Jun 2015 22:28:48 -0400, Jonathan M Davis
wrote:
Where on earth did you get the idea that in was introduced in 2.060?
DIP36:
"in ref has been allowed from 2.060 :
http://d.puremagic.com/issues/show_bug.cgi?id=8105";
Reading it more carefully this time, I understand what it's sa
On Wednesday, 3 June 2015 at 01:57:21 UTC, bitwise wrote:
On Tue, 02 Jun 2015 14:06:31 -0400, Namespace
wrote:
On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
wou
On Tue, 02 Jun 2015 14:06:31 -0400, Namespace wrote:
On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I would
implement it (if no one else wants to do it), but there
On 3 June 2015 at 07:21, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 6/2/15 11:19 AM, Jonathan M Davis wrote:
>>
>> On Tuesday, 2 June 2015 at 18:05:20 UTC, Namespace wrote:
>>>
>>> AFAIK Andrei wanted 'auto ref' as the syntax which accepts both,
>>> lvalues and rvalues. That's why I'm askin
On 6/2/15 2:28 PM, Namespace wrote:
On Tuesday, 2 June 2015 at 21:20:49 UTC, Andrei Alexandrescu wrote:
Yah, auto ref for templates is great. We only need to add auto ref for
non-templates with the semantics "like ref, except (a) accepts rvalues
on the caller side, (b) does not allow escaping th
On Tuesday, 2 June 2015 at 21:20:49 UTC, Andrei Alexandrescu
wrote:
Yah, auto ref for templates is great. We only need to add auto
ref for non-templates with the semantics "like ref, except (a)
accepts rvalues on the caller side, (b) does not allow escaping
the ref from the function".
That woul
On 6/2/15 11:19 AM, Jonathan M Davis wrote:
On Tuesday, 2 June 2015 at 18:05:20 UTC, Namespace wrote:
AFAIK Andrei wanted 'auto ref' as the syntax which accepts both,
lvalues and rvalues. That's why I'm asking if the current behaviour
for auto ref for templates should change, or not. If not, we
3. Add a new attribute - e.g. @rvalue ref - which inserts a
temporary variable for rvalues so that they can be passed by
ref, and it works with both templated and non-templated
functions.
We could also somehow use 'return ref' for that purpose, or we
could get rid of the pointless 'const scop
On Tuesday, 2 June 2015 at 18:05:20 UTC, Namespace wrote:
AFAIK Andrei wanted 'auto ref' as the syntax which accepts
both, lvalues and rvalues. That's why I'm asking if the current
behaviour for auto ref for templates should change, or not. If
not, we have (as you said) two meanings of auto ref
auto ref with templated functions needs to retain its current
behavior. Changing it would not only break existing code, but
it would lose what we have in terms of perfect forwarding
(IIRC, it's not quite perfect forwarding, but it's close, and
we'd be much farther from it without auto ref).
Ok
On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), but there
are still some unanswered questions:
1. Is 'auto ref'
On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), but there
are still some unanswered questions:
1. Is 'auto ref'
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), but there
are still some unanswered questions:
1. Is 'auto ref' still the chosen syntax (I guess so)?
Why not `scope ref` (
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), but there
are still some unanswered questions:
1. Is 'auto ref' still the chosen syntax (I guess so)?
2. Should auto ref for
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), but there
are still some unanswered questions:
1. Is 'auto ref' still the chosen syntax (I guess so)?
2. Should auto ref for
On Thursday, 14 May 2015 at 06:56:47 UTC, Namespace wrote:
On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:
On Tue, 12 May 2015 08:54:15 -0400, Namespace
wrote:
As far as I know, the problem (or at least one of the biggest
problems) for rvalue references was that they could escape.
On Thu, 14 May 2015 16:12:36 -0400, Namespace wrote:
Don't ask me, I'm just a little light here.
But I think it's because 'in' means 'const scope' and as you said, scope
is out. ;)
Which means 'in' is available! ;)
Bit
Don't ask me, I'm just a little light here.
But I think it's because 'in' means 'const scope' and as you
said, scope is out. ;)
On Thursday, 14 May 2015 at 20:02:29 UTC, bitwise wrote:
On Thu, 14 May 2015 13:15:34 -0400, Namespace
wrote:
On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote:
If it were up to me, I would say:
'scope' should be removed as a storage class,
'ref' should be left as is, and
'in' should ad
On Thu, 14 May 2015 13:15:34 -0400, Namespace wrote:
On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote:
If it were up to me, I would say:
'scope' should be removed as a storage class,
'ref' should be left as is, and
'in' should adopt the behavior of 'ref' post DIP25
Bit
As Andrei sa
On Thursday, 14 May 2015 at 17:50:35 UTC, Andrei Alexandrescu
wrote:
On 5/14/15 10:15 AM, Namespace wrote:
But interesting question, what will happen with scope, now
that we have
return ref.
Evaluate its merit once we have everything else in. -- Andrei
Short and meaningful. Thank you.
On 5/14/15 10:15 AM, Namespace wrote:
But interesting question, what will happen with scope, now that we have
return ref.
Evaluate its merit once we have everything else in. -- Andrei
On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote:
On Thu, 14 May 2015 02:56:46 -0400, Namespace
wrote:
On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:
Side note: DIP36 seems to be missing the table with the
authors, status, etc.
Bit
Huh, DIP36? DIP36 was rejected, but
On Thu, 14 May 2015 02:56:46 -0400, Namespace wrote:
On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:
Side note: DIP36 seems to be missing the table with the authors,
status, etc.
Bit
Huh, DIP36? DIP36 was rejected, but the authors (me and Dicebot) are
below.
Hmm.. so the
On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:
On Tue, 12 May 2015 08:54:15 -0400, Namespace
wrote:
As far as I know, the problem (or at least one of the biggest
problems) for rvalue references was that they could escape.
Since DIP25 is approved and already implemented this problem
On Tue, 12 May 2015 08:54:15 -0400, Namespace wrote:
As far as I know, the problem (or at least one of the biggest problems)
for rvalue references was that they could escape. Since DIP25 is
approved and already implemented this problem should be solved. Would it
be possible to allow rvalue
On Tue, 12 May 2015 08:54:15 -0400, Namespace wrote:
As far as I know, the problem (or at least one of the biggest problems)
for rvalue references was that they could escape. Since DIP25 is
approved and already implemented this problem should be solved. Would it
be possible to allow rvalue
No draft so far?
I feel I should mention a detail I observed. I am working on a
library which generates D code from C++ code with wrappers. I
found an interesting situation when I realised that I need to do
something like this.
void setPosition(ref const(QPoint) point) {
...
// Static array.
aut
Am Wed, 24 Apr 2013 13:41:05 +1000
schrieb Manu :
> >
> >
> > On 24 April 2013 11:02, Diggory wrote:
> >
> >> On Wednesday, 24 April 2013 at 00:54:12 UTC, kenji hara wrote:
> >>
> >>> 2013/4/24 Manu
> >>>
> >>> "The r-value being passed is assigned to a stack allocated temporary,
> which h
On Sun, 26 May 2013 18:56:58 -0400, Timothee Cour
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. It incurs a runtime che
> 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 ref-retu
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 uni
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 "saf
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 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 c
On 5 May 2013 10:37, 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 understandin
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 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 Monday, 6 May 2013 at 14:05:48 UTC, Andrei Alexandrescu wrote:
template 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 pa
On Mon, 06 May 2013 13:53:10 -0400, Andrei Alexandrescu
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:
foo(foo(foo(1)));
Is that ri
On 5/6/13 1:45 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 13:28:18 -0400, Andrei Alexandrescu
wrote:
On 5/6/13 12:17 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
wrote:
No. It's a very different thing handled by a special rule in C++.
Th
On Mon, 06 May 2013 13:28:18 -0400, Andrei Alexandrescu
wrote:
On 5/6/13 12:17 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
wrote:
No. It's a very different thing handled by a special rule in C++.
This isn't helping. You keep saying its differen
On 5/6/13 12:20 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 09:43:38 -0400, Andrei Alexandrescu
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 th
On 5/6/13 12:17 PM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
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 reference is returned, in the other a
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.
No
On Mon, 06 May 2013 09:43:38 -0400, Andrei Alexandrescu
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, combined with D's propensity t
On Mon, 06 May 2013 12:03:27 -0400, Andrei Alexandrescu
wrote:
On 5/6/13 11:48 AM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu
wrote:
Consider the body of min isn't known (eliminate templates etc). Then
what the compiler sees is a function call that
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
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 is it's a valid reference whi
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 Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu
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 simpler and cleaner D code?
No
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;
1 - 100 of 274 matches
Mail list logo
