https://issues.dlang.org/show_bug.cgi?id=14838
--- Comment #2 from Martin Nowak c...@dawg.eu ---
*** Issue 14839 has been marked as a duplicate of this issue. ***
--
https://issues.dlang.org/show_bug.cgi?id=14838
--- Comment #5 from Martin Nowak c...@dawg.eu ---
And struct postblits.
struct Array(T) { this(this) @safe {} }
struct Test { Array!int[1] array; }
bug2.d(2): Error: safe function 'bug2.Test.__fieldPostblit' cannot call system
function
||ag0ae...@gmail.com
Summary|Wrong attribute inference |[REG 2.066] Wrong attribute
|for auto-generated class|inference for
|destructor with static |auto-generated class
|array of non-POD type
https://issues.dlang.org/show_bug.cgi?id=14838
Issue ID: 14838
Summary: Wrong attribute inference for auto-generated class
destructor with static array of non-POD type
Product: D
Version: D2
Hardware: All
OS
On Friday, 24 July 2015 at 15:01:29 UTC, Adam D. Ruppe wrote:
On Friday, 24 July 2015 at 14:48:30 UTC, Marc Schütz wrote:
But I fail to see the relation to named parameters?
You can make your parameters into a struct or tuple and fill
them in with normal assignment. The with(auto) thing
(with(ParameterTypeTuple!foo) {
abc = 2,
def = 3
});
Or just:
auto args = with(ParameterTypeTuple!foo) {
abc = 2,
def = 3
};
foo(args);
For initialization:
auto a = with(new FooBar()) {
name = Foo,
bar = 3
};
Or:
with(new Thread(foo) {
isDaemon = true
}).start();
Sadly it'll
https://issues.dlang.org/show_bug.cgi?id=14381
Mathias LANG pro.mathias.l...@gmail.com changed:
What|Removed |Added
Blocks|3031|
--
find this one a bit ugly):
foo(with(ParameterTypeTuple!foo) {
abc = 2,
def = 3
});
Or just:
auto args = with(ParameterTypeTuple!foo) {
abc = 2,
def = 3
};
foo(args);
For initialization:
auto a = with(new FooBar()) {
name = Foo,
bar = 3
};
Or:
with(new Thread(foo
https://issues.dlang.org/show_bug.cgi?id=14381
Mathias LANG pro.mathias.l...@gmail.com changed:
What|Removed |Added
Blocks||3031
--
to
make it an expression.
For named parameters (admittedly, I find this one a bit ugly):
foo(with(ParameterTypeTuple!foo) {
abc = 2,
def = 3
});
Or just:
auto args = with(ParameterTypeTuple!foo) {
abc = 2,
def = 3
};
foo(args);
For initialization:
auto a = with(new FooBar
On 07/26/15 17:56, Idan Arye via Digitalmars-d wrote:
On Sunday, 26 July 2015 at 14:49:40 UTC, Timon Gehr wrote:
Well, no. That does not follow. We can have both a with statement and a with
expression.
Mmm... but how will we differ them?
There's no need for that. (hint: mixin). But,
On 07/24/2015 05:01 PM, Adam D. Ruppe wrote:
.ironically, given the other thread about statements as expressions
where i said 'meh', this is actually a decent case for them too, to get
the return value of foo out of that scope while still allowing auto.
It would make sense to extend
On Fri, 24 Jul 2015 14:12:39 +, Shammah Chancellor wrote:
This operation doesn't seem to work. It would be a pretty handy thing
to work since we don't support named parameters at this time.
Comments?
https://issues.dlang.org/show_bug.cgi?id=13526
signature.asc
Description: PGP
This operation doesn't seem to work. It would be a pretty handy
thing to work since we don't support named parameters at this
time.
Comments?
On Friday, 24 July 2015 at 14:48:30 UTC, Marc Schütz wrote:
But I fail to see the relation to named parameters?
You can make your parameters into a struct or tuple and fill them
in with normal assignment. The with(auto) thing will conveniently
limit the scope of the temporary argument object
On Friday, 24 July 2015 at 15:01:29 UTC, Adam D. Ruppe wrote:
On Friday, 24 July 2015 at 14:48:30 UTC, Marc Schütz wrote:
But I fail to see the relation to named parameters?
You can make your parameters into a struct or tuple and fill
them in with normal assignment. The with(auto) thing
On Friday, 24 July 2015 at 14:12:39 UTC, Shammah Chancellor wrote:
This operation doesn't seem to work. It would be a pretty
handy thing to work since we don't support named parameters at
this time.
Comments?
This limitation could probably be lifted easily.
But I fail to see the relation
On Wednesday, 15 July 2015 at 22:42:05 UTC, Steven wrote:
Does this mean that while compilers are expected to take
advantage of them, they currently do not, even when they have
proper alignment? I haven't tried LDC yet, so maybe LDC does
perform auto-vectorization and I should attempt to use
On 16 July 2015 at 00:42, Steven via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I was trying to show someone how awesome Dlang was earlier, and how the
vector operations are expected to take advantage of the CPU vector
instructions, and was dumbstruck when dmd and gdc both failed to
auto
On Wednesday, 15 July 2015 at 22:42:05 UTC, Steven wrote:
I was trying to show someone how awesome Dlang was earlier, and
how the vector operations are expected to take advantage of the
CPU vector instructions, and was dumbstruck when dmd and gdc
both failed to auto-vectorize a simple case
I was trying to show someone how awesome Dlang was earlier, and
how the vector operations are expected to take advantage of the
CPU vector instructions, and was dumbstruck when dmd and gdc both
failed to auto-vectorize a simple case. I've stripped it down to
the bare minimum and loaded
On Wednesday, 15 July 2015 at 22:42:05 UTC, Steven wrote:
I was trying to show someone how awesome Dlang was earlier, and
how the vector operations are expected to take advantage of the
CPU vector instructions, and was dumbstruck when dmd and gdc
both failed to auto-vectorize a simple case
On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu
wrote:
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
On Sunday, 28 June 2015 at 13:08:48 UTC, rsw0x wrote:
On Sunday, 28 June 2015 at 11:06:01 UTC, Marc Schütz wrote:
On Sunday, 28 June 2015 at 07:36:41 UTC, Jonathan M Davis
wrote:
It makes no sense to pass rvalues by ref. The ref has to
refer to a memory location so that a pointer can be passed
if the type is big.
So for efficiency, template auto-ref is a nice option, but
requires a template and leads to code-bloat if both lvalues and
rvalues are used as arguments. For these reasons, we want to have
the additional option to pass both lvalues and rvalues by ref.
Jonathan wants a non-templated
your POV the
following would be an ideal situation (disregarding the need
to avoid breaking changes):
1) `auto ref` for non-templates is required to make a
function accept rvalue and lvalue refs alike.
2) `auto ref` for templates is changed to mean the same thing
as 1).
3) `scope ref
This is semi-off-topic, but I was playing around... and line 12
broke my personal record for the most insane line ever written,
maybe someone else finds it amusing also:
[asm.dlang.org]
http://goo.gl/ChdbwD
(disregarding the need
to avoid breaking changes):
1) `auto ref` for non-templates is required to make a function
accept rvalue and lvalue refs alike.
2) `auto ref` for templates is changed to mean the same thing
as 1).
3) `scope ref` prevents escaping of the reference.
Neither of `auto ref
On Sunday, 28 June 2015 at 10:50:10 UTC, Marc Schütz wrote:
Thank you Jonathan, I think I (like kinke in his post above)
finally understand your stance. So I guess from your POV the
following would be an ideal situation (disregarding the need to
avoid breaking changes):
1) `auto ref` for non
On Monday, 29 June 2015 at 17:19:48 UTC, Jonathan M Davis wrote:
On Sunday, 28 June 2015 at 10:50:10 UTC, Marc Schütz wrote:
The main problems with this is that they aren't in fact
orthogonal: `auto ref` without `scope ref` almost only makes
sense if you want to deliberately break something
All values must be passed by ref because otherwise it will be
leading for code bloat : we want eliminate by having only one
function that accepts both rvalues and lvalues.
On Sunday, 28 June 2015 at 11:06:01 UTC, Marc Schütz wrote:
On Sunday, 28 June 2015 at 07:36:41 UTC, Jonathan M Davis wrote:
It makes no sense to pass rvalues by ref. The ref has to refer
to a memory location so that a pointer can be passed
underneath the hood, and rvalues don't qualify for
On Sunday, 28 June 2015 at 05:46:11 UTC, Manu wrote:
On 28 June 2015 at 08:50, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[..]
That's what auto ref was originally introduced to do. The
reason that it works only with templates is because Walter
misunderstood what
Thank you Jonathan, I think I (like kinke in his post above)
finally understand your stance. So I guess from your POV the
following would be an ideal situation (disregarding the need to
avoid breaking changes):
1) `auto ref` for non-templates is required to make a function
accept rvalue
On Sunday, 28 June 2015 at 07:36:41 UTC, Jonathan M Davis wrote:
It makes no sense to pass rvalues by ref. The ref has to refer
to a memory location so that a pointer can be passed underneath
the hood, and rvalues don't qualify for that.
I strongly disagree with that. This is an
).
That's a completely orthogonal issue to ref or auto ref. That's
an @system operation (since taking the address of a local
variable is @system), and it's up to you to not screw it up.
scope might cover that if it were fully ironed out, since that
does involve escaping, but it also might
On Saturday, 27 June 2015 at 11:10:49 UTC, Marc Schütz wrote:
On Saturday, 27 June 2015 at 01:18:19 UTC, Jonathan M Davis
wrote:
That's a completely orthogonal issue to ref or auto ref.
That's an @system operation (since taking the address of a
local variable is @system), and it's up to you
) to fix this problem. So, with that, we eliminate the
safety problem with ref itself, and we can safely have auto
ref accept rvalues by having it assign them to a temporary
variable first.
Yes this is now possible, but why in all world do you want the
keyword that enables it to be `auto ref
On 28 June 2015 at 08:50, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[..]
That's what auto ref was originally introduced to do. The reason that it
works only with templates is because Walter misunderstood what Andrei was
proposing. So, it makes sense to use
a pointer to a ref
parameter somewhere outside (global/instance variable).
That's a completely orthogonal issue to ref or auto ref. That's
an @system operation (since taking the address of a local
variable is @system), and it's up to you to not screw it up.
scope might cover that if it were
)));
// promote forwarded rvalue ref to lvalue
S s3 = forward(S(3));
// let the lvalue escape and manipulate it indirectly
auto state = new State();
state.initByEscaping(forward(s3)); // requires lvalue `ref`,
forward() returns that for lvalue arg
state.manipulate();
// GC
a
solution for rvalue refs for years, and, as you know, are waiting
since then, as `auto ref` for templates alone is simply not
enough.
To quote Manu from the DIP36 thread:
It is, without doubt, the single biggest complaint I've heard
by virtually every programmer I've introduced D to.
+1
On Thursday, 25 June 2015 at 08:04:09 UTC, kink wrote:
On Wednesday, 24 June 2015 at 23:30:53 UTC, Jonathan M Davis
wrote:
But this has _nothing_ to do with scope, and scope ref was
already rejected. The whole point of this is support having a
function accept both rvalues and lvalues, not to
to
repeatedly convince Walter and Andrei to have scope ref do
something similar to what we're talking about auto ref doing,
Walter and Andrei repeatedly shot it down. They had no interest
in having scope ref as any kind of special attribute. So, as of
the beginning of May 2013 (which was less than
On 06/25/2015 10:28 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
trying to expand it with scope ref as if that were simply an
extension of scope makes no sense. Before we can even consider what
something like scope ref might mean, we'd have to properly define what
scope means.
On Wednesday, 24 June 2015 at 17:47:51 UTC, Namespace wrote:
On Wednesday, 24 June 2015 at 17:45:15 UTC, Marc Schütz wrote:
On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in
On Wednesday, 24 June 2015 at 23:30:53 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 16:39:22 UTC, kink wrote:
On Wednesday, 24 June 2015 at 11:19:04 UTC, Jonathan M Davis
wrote:
[...]
3. Add a new attribute which does what's being proposed for
auto ref for non-templated
On 22 Jun 2015 08:40, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 6/21/15 11:31 PM, Andrei Alexandrescu wrote:
On 6/21/15 10:25 PM, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
I don't think
Simply give a possibility to ref in allowing use rvalues.
Don't add any new strange attributes.
On Wednesday, 24 June 2015 at 00:23:42 UTC, Timon Gehr wrote:
On 06/23/2015 03:01 AM, Andrei Alexandrescu wrote:
the perfect solution.
We might as well do it right. Why promote unnecessary template
bloat?
I'm fine with it either way, but given all of the template bloat
that auto ref
On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
And I still think Timon's statement is untrue. There is a
reason, which is that the new auto ref syntax forces reference
parameters for all types(even primitives), where the old
template approach does not.
The old template approach
On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in allowing use rvalues.
That has already been rejected.
- Jonathan M Davis
How many times did I say that already? :)
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in allowing use rvalues.
That has already been rejected.
- Jonathan M Davis
On Wednesday, 24 June 2015 at 10:02:12 UTC, Namespace wrote:
On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in allowing use rvalues.
That has already been rejected.
- Jonathan M
On Wednesday, 24 June 2015 at 16:39:22 UTC, kink wrote:
On Wednesday, 24 June 2015 at 11:19:04 UTC, Jonathan M Davis
wrote:
[...]
3. Add a new attribute which does what's being proposed for
auto ref for non-templated functions, in which case, we can
use the non-templated behavior
On Wednesday, 24 June 2015 at 11:19:04 UTC, Jonathan M Davis
wrote:
[...]
3. Add a new attribute which does what's being proposed for
auto ref for non-templated functions, in which case, we can use
the non-templated behavior with templates as well and thus
avoid template bloat when all you
:
On 6/21/15 10:25 PM, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
I don't think that lowering is recommended - it prolongs the lifetime of
the temporary through the end of the caller. But that may be actually a
good
thing
On Wednesday, 24 June 2015 at 17:45:15 UTC, Marc Schütz wrote:
On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in allowing use rvalues.
That has already been rejected.
Then we
to:
auto tmp = 5;
fun(tmp);
I don't think that lowering is recommended - it prolongs the
lifetime of the temporary through the end of the caller. But
that may be actually a good thing.
On second thought - Walter's lowering, which makes the rvalue
last more
than strictly necessary
On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in allowing use rvalues.
That has already been rejected.
Then we need to reconsider it. If that was several years ago,
much has
On Tuesday, 23 June 2015 at 09:57:26 UTC, Marc Schütz wrote:
On Monday, 22 June 2015 at 19:05:28 UTC, kinke wrote:
[...]
To clarify: What I meant by my comment was that const-ness
should not be a precondition for allowing rvalue refs. Mutable
rvalue refs are fine.
I know and see it the same
.
auto is worse because, if you later decide you need to add a
template parameter then the meaning is changed and you get a
_hidden_ performance issue.
Thus requiring neither auto nor const is the least evil of the
above.
You could always use comments, or even dummy aliases to make the
code self
.
- Jonathan M Davis
Thus the solution cannot require const.
auto is worse because, if you later decide you need to add a
template parameter then the meaning is changed and you get a
_hidden_ performance issue.
And how does it introduce a hidden performance issue. You'd end
up with some template
On Tuesday, 23 June 2015 at 12:45:25 UTC, kink wrote:
On Tuesday, 23 June 2015 at 09:57:26 UTC, Marc Schütz wrote:
To guarantee this from the caller's POV, the callee must be
pure and the parameters must be known not to alias each other.
This is obviously true. Rvalues aren't affected as they
On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis wrote:
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis
wrote:
[...]
Thus the solution cannot require const.
auto is worse because, if you later decide you need
. The two mechanisms shouldn't share the same
syntax, because then there is no way to tell them apart for template
functions.
You would be losing the optimization of passing primitive types by
value, wouldn't you?
Not if you keep the current `auto ref` template syntax AND introduce
On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr timon.g...@gmx.ch wrote:
There is no reason to prevent templates from using the mechanism that
generates only one copy. The two mechanisms shouldn't share the same
syntax, because then there is no way to tell them apart for template
functions.
On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
And I still think Timon's statement is untrue. There is a
reason, which is that the new auto ref syntax forces reference
parameters for all types(even primitives), where the old
template approach does not.
Timon suggested using another
then there is no way
to tell them apart for template functions.
You would be losing the optimization of passing primitive types
by value, wouldn't you?
Not if you keep the current `auto ref` template syntax AND
introduce another syntax `scope ref` for non-escapable references
also accepting rvalues.
const.
auto is worse because, if you later decide you need to add a
template parameter then the meaning is changed and you get a
_hidden_ performance issue.
And how does it introduce a hidden performance issue. You'd
end up with some template bloat, but that's it, and that's
just going
On Tuesday, 23 June 2015 at 17:05:41 UTC, John Colvin wrote:
On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis
wrote:
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
[...]
And how does it introduce a hidden performance issue. You'd
end up with some template bloat, but
On Monday, 22 June 2015 at 18:10:11 UTC, Andrei Alexandrescu
wrote:
On 6/22/15 9:54 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
`auto ref` without a working `scope` implementation is unsafe.
I'm unclear on this. With the existence of the return
attribute, what's unsafe about
imho.
As different behavior for templated `auto ref` and non-template
`auto ref` seems to be an issue for more people here, why don't
just rename the non-templated one `scope ref`, so that it's
usable for templates too and also enables the `in ref` shortcut
for const? I find `const auto ref
On Monday, 22 June 2015 at 19:05:28 UTC, kinke wrote:
On Monday, 22 June 2015 at 16:54:50 UTC, Marc Schütz wrote:
With the difference that C++ requires const-ness.
Yep, so `in ref T` translating to `scope const ref T` would be
D's convenient and safe counterpart to C++' `const T`
On Tuesday, 23 June 2015 at 01:07:17 UTC, Jonathan M Davis wrote:
No, you can't guarantee that an auto ref parameter won't be
mutated, but auto ref clearly indicates that you intend to
accept both lvalues and rvalues, meaning that it would be
stupid to be writing the function with the idea
them apart for
template
functions.
I understand. For my money I'd be okay with what's being
proposed instead of complicating the language yet again for the
perfect solution. -- Andrei
There is no perfect solution. :) Some are for in/scope ref, some
are against it. Some are for auto ref, some
On Tuesday, 23 June 2015 at 06:49:50 UTC, Daniel N wrote:
On Tuesday, 23 June 2015 at 01:07:17 UTC, Jonathan M Davis
wrote:
No, you can't guarantee that an auto ref parameter won't be
mutated, but auto ref clearly indicates that you intend to
accept both lvalues and rvalues, meaning
On 06/23/2015 03:01 AM, Andrei Alexandrescu wrote:
On 6/22/15 4:09 PM, Timon Gehr wrote:
There is no reason to prevent templates from using the mechanism that
generates only one copy. The two mechanisms shouldn't share the same
syntax, because then there is no way to tell them apart for
please let us
concentrate and discuss how we could solve this problem with auto
ref. :)
To repeat my statement from the PR:
I would also prefer to avoid the generation of further functions,
because I want to avoid the code bloat. I like the way of the
current implementation, because
scope and escape analysis could do a better job is unclear
and if you want to solve the problem this way you will wait a
very long time.
Not at all. `auto ref` without a working `scope` implementation
is unsafe. If that is acceptable for now, then it should be just
as acceptable to already use
We had this discussion already with DIP 36. A PR still exists
AFAIK, but because it was rejected I don't think that's going to
happen. :) So auto ref is obviously the choice. If you insist on
scope/in ref, please make your own thread and ask why it was
rejected or read the corresponding thread.
On 6/22/15 3:04 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
Just lower it to:
{
auto tmp = 5;
fun(tmp);
}
You need to lower an expression to an expression, not a statement. (e.g.
what if fun returns a result?)
I considered this lowering for int fun
On Monday, 22 June 2015 at 13:49:21 UTC, Steven Schveighoffer
wrote:
On 6/20/15 10:26 PM, Yuxuan Shui wrote:
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't
On Monday, 22 June 2015 at 13:49:31 UTC, Jonathan M Davis wrote:
On Monday, 22 June 2015 at 13:23:47 UTC, Marc Schütz wrote:
On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu
wrote:
Walter and I discussed what auto ref for templates should
look like and reached the conclusion
On Monday, 22 June 2015 at 15:39:38 UTC, Andrei Alexandrescu
wrote:
On 6/22/15 3:04 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Just lower it to:
{
auto tmp = 5;
fun(tmp);
}
You need to lower an expression to an expression, not a
statement. (e.g
On 6/22/15 1:37 PM, Yuxuan Shui wrote:
On Monday, 22 June 2015 at 13:49:21 UTC, Steven Schveighoffer wrote:
On 6/20/15 10:26 PM, Yuxuan Shui wrote:
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R
On Monday, 22 June 2015 at 05:25:57 UTC, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
But when talking to Andrei I didn't realize that it would be
subtly different behavior than 'auto ref' for template
functions, which makes me concerned
On Monday, 22 June 2015 at 20:50:23 UTC, Namespace wrote:
That would be horrible. How would you distinguish between
lvalues and rvalues? What if you want to store a pointer to an
lvalue? If ref accept both you cannot do that.
storing requires 'return ref'
On Monday, 22 June 2015 at 20:42:58 UTC, Daniel N wrote:
On Monday, 22 June 2015 at 05:25:57 UTC, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
But when talking to Andrei I didn't realize that it would be
subtly different behavior than 'auto
It's no worse than auto ref. It's only by convention that auto
ref functions doesn't mutate, at least I follow that convention,
but when looking at someone else's function, all bets are off.
the proposed `in ref T`/`const auto ref T` *shudder*
equivalents if const-transitiveness would be violated. In my
day-to-day C++ work, I almost never have to do that.
Note almost.
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
Try to compile this code snippet:
import std.traits;
template a(R) {
auto a(S)(auto ref R i) {
return cast(S)i*2;
}
}
template ReturnTypeEx(alias A, B) {
alias ReturnTypeEx = ReturnType!(A!B
On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote:
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
On 06/23/2015 12:40 AM, Andrei Alexandrescu wrote:
On 6/22/15 3:06 PM, Timon Gehr wrote:
On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote:
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
On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu
wrote:
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
On Sunday, 21 June 2015 at 02:37:59 UTC, Yuxuan Shui wrote:
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't
understand.
But R is not a parameter on the function
restriction imposed by D and only
prevents
you from using the proposed `in ref T`/`const auto ref T`
*shudder*
equivalents if const-transitiveness would be violated. In my
day-to-day C++ work, I almost never have to do that.
Note almost.
Ah, I remember you from another rvalue discussion some years
https://issues.dlang.org/show_bug.cgi?id=5941
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 6/22/15 4:09 PM, Timon Gehr wrote:
There is no reason to prevent templates from using the mechanism that
generates only one copy. The two mechanisms shouldn't share the same
syntax, because then there is no way to tell them apart for template
functions.
I understand. For my money I'd be
it is.
It's just an additional restriction imposed by D and only prevents
you from using the proposed `in ref T`/`const auto ref T` *shudder*
equivalents if const-transitiveness would be violated. In my
day-to-day C++ work, I almost never have to do that.
Note almost.
...
Care to share
1101 - 1200 of 2922 matches
Mail list logo
