There's a need in generic code to have a function take a parameter by
ref if it is an lvalue, and by value if it is an rvalue. This can be
addressed by making it a template using auto ref:
T foo(T)(auto ref T x) { ... }
foo(3)// call by value
int y;
foo(y)// call by refe
On 16/12/2009 07:18, Walter Bright wrote:
There's a need in generic code to have a function take a parameter by
ref if it is an lvalue, and by value if it is an rvalue. This can be
addressed by making it a template using auto ref:
T foo(T)(auto ref T x) { ... }
foo(3) // call by value
exactly.
If so I'm a little confused by 'auto ref foo(...' - if auto ref here is
also simply an 'apply ref in the case of lvalue', then where is the
return type being inferred from?
From the return statement in the body of the function.
ref in the case of lvalue'?
Yes, exactly.
If so I'm a little confused by 'auto ref foo(...' - if auto ref here
is also simply an 'apply ref in the case of lvalue', then where is the
return type being inferred from?
From the return statement in the body of the f
Mikhail Dahl wrote:
That's what happens at 8am when you've
had no sleep.
I know the feeling well. Well enough that I don't even bother trying to
code when I feel that way, as after I get some sleep I have to unwind
all those "great ideas" I had when overtired.
On Dec 16, 09 15:18, Walter Bright wrote:
There's a need in generic code to have a function take a parameter by
ref if it is an lvalue, and by value if it is an rvalue. This can be
addressed by making it a template using auto ref:
T foo(T)(auto ref T x) { ... }
foo(3) // call by value
KennyTM~ Wrote:
> auto const?
I was wondering the same thing.
Jason House wrote:
KennyTM~ Wrote:
auto const?
I was wondering the same thing.
The const transport thing is, unfortunately, a very different problem.
d issues. This morning I read
about inout, return, vconst, aconst, sameconst, autoconst, auto const, and
bikeshed. At least one of those was in jest :) auto const isn't that bad, and
you obviously liked auto ref...
o through bikeshed issues. This morning I
read about inout, return, vconst, aconst, sameconst, autoconst, auto
const, and bikeshed. At least one of those was in jest :) auto const
isn't that bad, and you obviously liked auto ref...
I think one of the problems is that ref is a storage c
morning I
read about inout, return, vconst, aconst, sameconst, autoconst, auto
const, and bikeshed. At least one of those was in jest :) auto const
isn't that bad, and you obviously liked auto ref...
Since this is just a special kind of const, it could be called "const^"
(con
On 2009-12-16 19:05:09 -0500, Michel Fortin said:
Since this is just a special kind of const, it could be called "const^"
(const or a derived constness):
Bad editing. That should be "const?". Sorry if it confuses anyone.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
On Wed, 16 Dec 2009 12:00:46 +0100, KennyTM~ wrote:
On Dec 16, 09 15:18, Walter Bright wrote:
There's a need in generic code to have a function take a parameter by
ref if it is an lvalue, and by value if it is an rvalue. This can be
addressed by making it a template using auto ref:
T
On 12/17/2009 01:05 AM, Michel Fortin wrote:
Object? func(Object? o) {
writeln(o.toString());
return o;
}
MyObject o = func(new MyObject);
Here, "Object?" means Object or a derived type.
You know, just Object means Object or a derived type. That's what
inheritance is.
On 2009-12-17 01:57:50 -0500, Pelle Månsson said:
On 12/17/2009 01:05 AM, Michel Fortin wrote:
Object? func(Object? o) {
writeln(o.toString());
return o;
}
MyObject o = func(new MyObject);
Here, "Object?" means Object or a derived type.
You know, just Object means Object or a derived type.
On Dec 17, 09 19:44, Michel Fortin wrote:
On 2009-12-17 01:57:50 -0500, Pelle Månsson said:
On 12/17/2009 01:05 AM, Michel Fortin wrote:
Object? func(Object? o) {
writeln(o.toString());
return o;
}
MyObject o = func(new MyObject);
Here, "Object?" means Object or a derived type.
You know,
On 2009-12-17 07:09:57 -0500, KennyTM~ said:
On Dec 17, 09 19:44, Michel Fortin wrote:
On 2009-12-17 01:57:50 -0500, Pelle Månsson said:
On 12/17/2009 01:05 AM, Michel Fortin wrote:
Object? func(Object? o) {
writeln(o.toString());
return o;
}
MyObject o = func(new MyObject);
Here, "Objec
ue, and by value if it is an rvalue. This can be
> >>addressed by making it a template using auto ref:
> >>
> >>T foo(T)(auto ref T x) { ... }
> >>
> >>foo(3) // call by value
> >>int y;
> >>foo(y) // call by reference
> >>
"Michel Fortin" wrote in message
news:hgd9jb$26v...@digitalmars.com...
> On 2009-12-17 07:09:57 -0500, KennyTM~ said:
>
>> On Dec 17, 09 19:44, Michel Fortin wrote:
>>> On 2009-12-17 01:57:50 -0500, Pelle Månsson
>>> said:
>>>
On 12/17/2009 01:05 AM, Michel Fortin wrote:
> Object? fun
== Quote from Nick Sabalausky (a...@a.a)'s article
> Pardon my ignorance, but why is it that templated functions can't be
> virtual?
This is an unfortunate consequence of compilation model leaking out into
language
design. You're supposed to be able to subclass a base class even if you don't
hav
egligible amount of time to compile anyhow, I'd be in favor of this.
> However,
> for larger projects or projects that require things to work based only on
> interface, without access to the full source code, this is probably
> impractical.
This 'auto ref' stuff and t
rface, without access to the full source code, this is probably impractical.
This 'auto ref' stuff and the multi-flavor 'vconst' functions are
basically templates with a known list of instantiations (ref /no-ref,
and const/immutable/plain)
In theory there's no reason you
On Thu, 17 Dec 2009 13:03:51 -0500, Bill Baxter wrote:
This 'auto ref' stuff and the multi-flavor 'vconst' functions are
basically templates with a known list of instantiations (ref /no-ref,
and const/immutable/plain)
In theory there's no reason you couldn't
dsimcha:
>The only solution I see would be to completely get rid of separate
>compilation.<
"All problems in computer science can be solved by another level of
indirection;"
-- David Wheeler
But that also slows code down a little :-)
Bill Baxter:
Static interfaces are an
.
Of course, but it may still go through bikeshed issues. This morning I
read about inout, return, vconst, aconst, sameconst, autoconst, auto
const, and bikeshed. At least one of those was in jest :) auto const
isn't that bad, and you obviously liked auto ref...
Since this is just a sp
a parameter by
>>ref if it is an lvalue, and by value if it is an rvalue. This can be
>>addressed by making it a template using auto ref:
>>
>>T foo(T)(auto ref T x) { ... }
>>
>>foo(3) // call by value
>>int y;
>>foo(y) // call by reference
>>
&
On 2009-12-17 14:52:40 -0500, "Steven Schveighoffer"
said:
The interesting thing about it, beside not taking a keyword, is that it
can scale in the future if we need to add many distinct constness to
the same function signature:
const?(Object) func(const?(Object) o, const?2(Object) o2, o
On Thu, 17 Dec 2009 15:17:22 -0500, Michel Fortin
wrote:
On 2009-12-17 14:52:40 -0500, "Steven Schveighoffer"
said:
The interesting thing about it, beside not taking a keyword, is that
it can scale in the future if we need to add many distinct constness
to the same function signatur
"dsimcha" wrote in message
news:hgdpn2$t1...@digitalmars.com...
> == Quote from Nick Sabalausky (a...@a.a)'s article
>> Pardon my ignorance, but why is it that templated functions can't be
>> virtual?
>
> This is an unfortunate consequence of compilation model leaking out into
> language
> desig
== Quote from Nick Sabalausky (a...@a.a)'s article
> "dsimcha" wrote in message
> news:hgdpn2$t1...@digitalmars.com...
> > == Quote from Nick Sabalausky (a...@a.a)'s article
> >> Pardon my ignorance, but why is it that templated functions can't be
> >> virtual?
> >
> > This is an unfortunate conse
e now. Just putting the idea out
there because it seems like we're heading for a place where we solve
the problem of generating multiple versions of a function in three
completely different ways (auto ref, vconst and of course templates)
[four if you count generating them with string mixins]. I
Bill Baxter:
> I don't know
> what the proper generalization is, but I think if you try to keep
> templates the way they are while generalizing them to handle these
> cases you will end up with an unworkable notation nightmare.
It's not easy to design such large changes up-front (Andrei has for ex
Yes. We are actively looking into a complete solution. Along
the way we also very strongly want to define semantics of "ref"
in such a way that makes unsafe escapes impossible. These two
features are related.
Andrei
That's good to know. But can you estimate _when_ it will be
implemented or
about auto ref.
There are only some questions: Will auto ref be implemented in
the near
future or not?
Yes. We are actively looking into a complete solution. Along
the way we also very strongly want to define semantics of "ref"
in such a way that makes unsafe escapes impossible.
-knnghuzbzqddaqcjtvch:40forum.dlang.org
I hereby open up again the discussion about auto ref.
There are only some questions: Will auto ref be implemented
in the near
future or not?
Yes. We are actively looking into a complete solution. Along
the way we also very strongly want to define semantics of
"re
On Saturday, January 26, 2013 17:51:23 Namespace wrote:
> That's good to know. But can you estimate _when_ it will be
> implemented or with which version? That would be very informative.
Things generally just don't work that way around here. They get done when they
get done. And often some of the
dy for merging and usage. This pull adds functionality
for non-template auto refs but it doesn't change the (template)
auto ref functionality in general, as Kenjis pull does.
.
>
> Another proposal, that I've suggested in another thread, would be
> to merge some "placeholder" pull which fix the problem until the
> official solution is implemented. I thought about this pull:
> https://github.com/D-Programming-Language/dmd/pull/1428
> It
If we add a feature as a temporary measure and then remove it
later, we're
likely to end up breaking code when it's removed.
No, as far as I can see this don't happend. auto ref works
currently very well for template functions and the pull I suggest
adds the same functiona
On Sunday, January 27, 2013 01:32:07 Namespace wrote:
> > If we add a feature as a temporary measure and then remove it
> > later, we're
> > likely to end up breaking code when it's removed.
>
> No, as far as I can see this don't happend. auto ref w
On Sunday, 27 January 2013 at 01:23:18 UTC, Jonathan M Davis
wrote:
But it may not even end up being the case that using auto ref
on non-templated functions is the solution. It may end up being
something else entirely. Ignoring @safety issues, it seems to
me like it would be the most
On 01/26/2013 03:03 AM, Namespace wrote:
> with dmd 2.061 structs aren't lvalues anymore.
You mean, temporary struct objects are not lvalues anymore.
Ali
temporaries to
work right likely need to be at the top-most scope of whatever
function you happen to be in; Beyond that I'm not sure how else
the auto ref could be implemented safely.
I have yet to see an instance of such problem in real life, but
quite frankly, I tired to argue.
rValues to
lValues, then passing off the temporaries. The temporaries to
work right likely need to be at the top-most scope of whatever
function you happen to be in; Beyond that I'm not sure how
else the auto ref could be implemented safely.
I have yet to see an instance of such probl
allowed, but more
likely temporaries will be made for convertion from rValues
to lValues, then passing off the temporaries. The temporaries
to work right likely need to be at the top-most scope of
whatever function you happen to be in; Beyond that I'm not
sure how else the auto ref cou
On Sunday, January 27, 2013 07:28:24 deadalnix wrote:
> Back on the point, quoting « Having ref accept rValues seems like
> a bad idea. ». D accepted it for ages, some language accept it by
> design (java for instance).
>
> Now can someone show me the code ?
D's ref has never accepted rvalues. Ra
But it may not even end up being the case that using auto ref
on non-templated
functions is the solution. It may end up being something else
entirely.
Ignoring @safety issues, it seems to me like it would be the
most
straightforward solution, but there are @safety issues with ref
in general
On Sunday, January 27, 2013 10:47:42 Namespace wrote:
> Ehh, so if auto ref won't be the solution, we then have auto ref
> for template functions and another solution for non-ref
> functions? I don't think that that is a smart idea and that it
> would be a kind of inconsiste
I didn't know. I thought auto ref would be the only solutions for
non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background knowledge I will write my code twice, with and without
ref. Thank you.
likely need to be at the
top-most scope of whatever function you happen to be in; Beyond that I'm
not sure how else the auto ref could be implemented safely.
One simple matter that has been discussed here, which I've hit only
yesterday in a script was:
string lines;
...
auto r = regex(
lValues, then
passing off
the temporaries. The temporaries to work right likely need to
be at the
top-most scope of whatever function you happen to be in;
Beyond that I'm
not sure how else the auto ref could be implemented safely.
One simple matter that has been discussed here, which I&#
On 1/27/13 8:05 AM, deadalnix wrote:
It seems here that captures provide you a new copy every time. why not
after all ? What is the problem here ?
The property, which is intended to behave as a field as much as
possible, in this case continues to look like a field but doesn't act
like one. Th
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu
wrote:
The property, which is intended to behave as a field as much as
possible, in this case continues to look like a field but
doesn't act like one. That means that switching transparently
between a field and a property (the holy
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu
wrote:
On 1/27/13 8:05 AM, deadalnix wrote:
It seems here that captures provide you a new copy every time.
why not
after all ? What is the problem here ?
The property, which is intended to behave as a field as much as
possible,
On 1/27/13 9:30 AM, deadalnix wrote:
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu wrote:
On 1/27/13 8:05 AM, deadalnix wrote:
It seems here that captures provide you a new copy every time. why not
after all ? What is the problem here ?
The property, which is intended to beh
On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
I didn't know. I thought auto ref would be the only solutions
for non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background knowledge I will write my code twice, with and
without ref. Than
On Sunday, 27 January 2013 at 14:54:26 UTC, Namespace wrote:
On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
I didn't know. I thought auto ref would be the only solutions
for non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background know
And before I forget, can I also suggest a syntax?
I would love 'ref&'. ;) It's pretty short and smart.
On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis
wrote:
On Saturday, January 26, 2013 17:51:23 Namespace wrote:
That's good to know. But can you estimate _when_ it will be
implemented or with which version? That would be very
informative.
Things generally just don't work that wa
I would suggest that it should work this way, and that maybe
this should be part of the new process focus.
This isn't intended to be demanding -- it could be fairly
simple to provide SOME guide to timeframes. For example, with
redmine, you can attach issues to milestones/releases, and give
a
I have this program that used to compile with 72 but with 73 dmd
is complaining that
"Error: escaping reference to local variable t"
auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}
auto ref f1(T)(auto ref T t, auto ref T s) {
return f2(t, s);
}
unittest {
This has probably been discussed before, so someone has probably already
explained why this is a bad idea, but I can't remember why that would be, so
I'm going to ask:
Why can't we simply make auto ref work with non-templated functions by making
it automatically generate both
I think I'm opening a can of worms here, in regards to inferring
the escape of references, but a quick investigation showed me
that return by auto-ref is horribly broken.
Basically, the only thing it does is check if the very last value
it returns is a ref, but a ref to what
s « auto c = a + Number(123);
But in D we cannot. Why ? Because ref doesn't accept temp objects.
We need to use auto ref. OK, but auto ref cannot be used on
non-templated function.
We need even more make that function templated. It leads to a
code bloat.
I don't see a reason why « a
Walter and I discussed what auto ref for templates should look like and
reached the conclusion that an approach based on lowering would be best.
I added a proposed lowering to
https://github.com/D-Programming-Language/dmd/pull/4717.
Andrei
Poking around in the source code for emplace and I noticed...
T* emplace(T, Args...)(T* chunk, auto ref Args args)
what does the "auto ref" do in this situiation? Cant seem to find
any explanation in the docs.
On 24 January 2017 at 10:52, Robert burner Schadek via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I have this program that used to compile with 72 but with 73 dmd is
> complaining that
> "Error: escaping reference to local variable t"
>
> auto ref f
Nice idea, but didn't work either. Just got more errors. And my
eyes hurt now.
On Tuesday, 24 January 2017 at 00:52:34 UTC, Robert burner
Schadek wrote:
I have this program that used to compile with 72 but with 73
dmd is complaining that
"Error: escaping reference to local variable t"
auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}
auto ref
On Tuesday, 24 January 2017 at 06:51:40 UTC, Stefan Koch wrote:
On Tuesday, 24 January 2017 at 00:52:34 UTC, Robert burner
Schadek wrote:
I have this program that used to compile with 72 but with 73
dmd is complaining that
"Error: escaping reference to local variable t"
auto ref
complaining that
>>> "Error: escaping reference to local variable t"
>>>
>>> auto ref f2(T)(auto ref T t, auto ref T s) {
>>> return t;
>>> }
>>>
>>> auto ref f1(T)(auto ref T t, auto ref T s) {
>>> return f
On 01/24/2017 12:47 AM, Ali Çehreli wrote:
> Lvalues are passed by reference and rvalues are copied.
I keep making that mistake! Despite the by-copy syntax, rvalues are moved.
Ali
nal compilation with
`__traits(isRef)` as in
struct S {}
void f()(auto ref const S x)
{
static if (__traits(isRef, x)) // l-value `x` was passed by
ref
{
// special treatment of const ref x
}
else // r-value `x` was passed by move
{
// `x´ can be reused,
rote:
> >>> I have this program that used to compile with 72 but with 73 dmd is
> >>> complaining that
> >>> "Error: escaping reference to local variable t"
> >>>
> >>> auto ref f2(T)(auto ref T t, auto ref T s) {
>
On 01/24/2017 02:03 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Tuesday, January 24, 2017 00:47:31 Ali Çehreli via Digitalmars-d
wrote:
>> The problem with auto ref is that in the case of rvalues, what you have
>> is a local variable, which makes it almost given that
which take null when the caller does not care.
>
> So, is this the guideline? "Make the argument 'auto ref' when you have
> something to return in addition to the return value." If so, it's
> sub-obtimal because the 'auto ref' doesn't have the oppo
On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
wrote:
This has probably been discussed before, so someone has
probably already
explained why this is a bad idea, but I can't remember why that
would be, so
I'm going to ask:
Why can't we simply make auto re
On Monday, December 24, 2012 20:43:06 Robert Clipsham wrote:
> Is:
>
> auto foo()(auto ref S e) { /* do stuff */ }
>
> So hard to write?
>
> (It's Christmas Eve, and I can't be bothered giving real
> arguments against right now - I suppose someone else will
If nothing else, it doesn't work for classes, because templated
functions
can't be virtual. Also, it forces you to put the entire
function's
implementation in a .di file if you use .di files, which makes
it untentable for
many of the folks who actually need to use .di files.
We need a solution
On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
wrote:
Why can't we simply make auto ref work with non-templated
functions by making
it automatically generate both the ref and non-ref versions?
[snip]
What problems does this cause? Why haven't we just done this
alrea
On Tuesday, 25 December 2012 at 00:56:44 UTC, Peter Alexander
wrote:
On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
wrote:
And if that doesn't work, can we simply make it so that the
compiler
automatically creates a variable when you pass an rvalue to a
non-templated
aut
cally creates a variable when you pass an rvalue to a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't
thought too much about it.
If there are no problems with this way, then what I want to
know is why the template version of auto ref was
On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
>
> wrote:
> > Why can't we simply make auto ref work with non-templated
> > functions by making
> > it automatically generate b
What does this generate?
auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
d) { ... }
16 different functions, one for each combination? Sounds like a
bad idea.
In my opinion, this should produce only two functions:
#1: auto foo(ref S a, ref S b, ref S c, ref S d) { ... }
#2
Jonathan M Davis wrote:
> On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> > On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
> >
> > wrote:
> > > Why can't we simply make auto ref work with non-templated
> > > functions by
On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
> > What does this generate?
> >
> > auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
> > d) { ... }
> >
> > 16 different functions, one for each combination? Sounds like a
> > bad ide
On Tuesday, December 25, 2012 11:12:43 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> > > On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
> > >
> > > wrote:
> > > >
gt;
> > > > wrote:
> > > > > Why can't we simply make auto ref work with non-templated
> > > > > functions by making
> > > > > it automatically generate both the ref and non-ref versions?
> > > > >
> > > >
On Tuesday, December 25, 2012 11:44:45 Jens Mueller wrote:
> And the solution needs to be non-template based because it needs to work
> with classes? Is that the only reason?
That and if it's not non-templated, it's impossible to have auto ref functions
which hide their implemen
it so that the compiler
automatically creates a variable when you pass an rvalue to a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't thought
too much about it.
If there are no problems with this way, then what I want to know is
why the t
On 12/25/12 5:36 AM, Jonathan M Davis wrote:
On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
What does this generate?
auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
d) { ... }
16 different functions, one for each combination? Sounds like a
bad idea.
In my opinion
function still seems like it could
work.
Yes, that does work and is easy to implement.
Is there any reason this hasn't been implemented? And why aren't
template auto ref functions implemented like that? It would be a
bit of a shame if auto ref in template functions works
different
, Jonathan M
Davis wrote:
And if that doesn't work, can we simply make it so that the
compiler
automatically creates a variable when you pass an rvalue to
a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't
thought
too much about it.
12/25/2012 6:15 PM, Peter Alexander пишет:
On Tuesday, 25 December 2012 at 14:09:13 UTC, Andrei Alexandrescu wrote:
[snip]
void foo(auto ref S s1,auto ref S s2,...,auto ref s10)
compiler should generate 2^10 versions of function foo.
The compiler will only generate as many versions as
On 2012-12-25 15:11, Andrei Alexandrescu wrote:
Yes, that does work and is easy to implement.
That's also what one needs to do now.
--
/Jacob Carlborg
> On 2012-12-25 15:11, Andrei Alexandrescu wrote:
>> Yes, that does work and is easy to implement.
This also solves the problem of taking the address of the `auto ref`
function or method. Two birds with one stone.
Yes, that does work and is easy to implement.
Andrei
And why isnt it in 2.061? ;)
On Tuesday, 25 December 2012 at 14:11:14 UTC, Andrei Alexandrescu
wrote:
On 12/25/12 5:36 AM, Jonathan M Davis wrote:
On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
What does this generate?
auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
d) { ... }
16 different
, Jonathan M
Davis wrote:
And if that doesn't work, can we simply make it so that the
compiler
automatically creates a variable when you pass an rvalue to
a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't
thought
too much about it.
by ref and needs to mutate its argument.
With auto ref, you're specifically saying that you don't care whether the
function is given an lvalue or rvalue. You just want it to avoid unnecessary
copies. That's very different. And auto ref then not only then protects you
from cases of
1 - 100 of 253 matches
Mail list logo
