On Sunday, 26 January 2014 at 12:01:18 UTC, Stanislav Blinov
wrote:
then only way to go about it is to return int by ref.
s/int/it/
On Sunday, 26 January 2014 at 07:21:15 UTC, Stanislav Blinov
wrote:
On Saturday, 25 January 2014 at 18:47:17 UTC, Andrei
Alexandrescu wrote:
We plan to disallow taking address of a ref return from a
function.
What about sneaky cases? E.g. like this:
NullableRef!T nref(T)(ref T v) {
25-Jan-2014 02:13, Stanislav Blinov пишет:
On Friday, 24 January 2014 at 19:54:31 UTC, Dmitry Olshansky wrote:
2 unrelated questions would be better as 2 nice smaller posts.
Just saying.
I know. Sorry if it got you irritated. I have a feeling I'll be coming
back with questions that are based
25-Jan-2014 02:13, Stanislav Blinov пишет:
On Friday, 24 January 2014 at 19:54:31 UTC, Dmitry Olshansky wrote:
If I understand the current direction is to go with ref T and make
some language
level/compiler level changes to the escaping reference.
Escaping... where? By go with ref T you mean
On Saturday, 25 January 2014 at 10:03:55 UTC, Dmitry Olshansky
wrote:
In fact, the definition above
would even fail to compile in this case, because push should
take
shared(T) and pop should return shared(T) (since Queue will be
dealing
with a container of shared Ts, right?)
No Queue in
On Saturday, 25 January 2014 at 11:51:04 UTC, Dmitry Olshansky
wrote:
Escaping... where? By go with ref T you mean return value of
e.g.
front()?
Say front returns a reference to a first element in an array.
Say user stores someArray.front as pointer somewhere, and the
does
On 1/25/14 3:51 AM, Dmitry Olshansky wrote:
25-Jan-2014 02:13, Stanislav Blinov пишет:
On Friday, 24 January 2014 at 19:54:31 UTC, Dmitry Olshansky wrote:
If I understand the current direction is to go with ref T and make
some language
level/compiler level changes to the escaping reference.
On Saturday, 25 January 2014 at 18:47:17 UTC, Andrei Alexandrescu
wrote:
We plan to disallow taking address of a ref return from a
function.
What about sneaky cases? E.g. like this:
NullableRef!T nref(T)(ref T v) { return NullableRef!T(v); }
struct Container(T) {
//...
ref
Ok, this is going to be a long one, so please bear with me.
I'll start with a question.
1. std.algorithm.move() and std.container
TDPL describes when a compiler can and cannot perform a move
automatically.
For cases when it isn't done automatically but we explicitly
require a move, we have
Ouch. Please excuse the formatting. I didn't pay attention when
pasting this :|
24-Jan-2014 21:07, Stanislav Blinov пишет:
Ok, this is going to be a long one, so please bear with me.
I'll start with a question.
2 unrelated questions would be better as 2 nice smaller posts.
Just saying.
1. std.algorithm.move() and std.container
[snip]
But why is there no practical
On Friday, 24 January 2014 at 19:54:31 UTC, Dmitry Olshansky
wrote:
2 unrelated questions would be better as 2 nice smaller posts.
Just saying.
I know. Sorry if it got you irritated. I have a feeling I'll be
coming back with questions that are based on both move() and
shared tied up
12 matches
Mail list logo
