On Wednesday, 25 July 2018 at 18:37:55 UTC, Manu wrote:
On Wed, 25 Jul 2018 at 10:45, Atila Neves via Digitalmars-d
wrote:
On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
But my point is, that exact reasoning extends to the
hypothetical ref
argument as the return value.
If a
On Wednesday, 25 July 2018 at 21:55:00 UTC, Manu wrote:
On Wed, 25 Jul 2018 at 13:55, 12345swordy via Digitalmars-d
wrote:
> It's not a false equivalence fallacy: all the discussion is
> about IMPLICIT conversion or rvalues to lvalues.
Yes it is, the issues regarding rvalue/lvalue conversion
On Wed, 25 Jul 2018 at 13:55, 12345swordy via Digitalmars-d
wrote:
>
> > It's not a false equivalence fallacy: all the discussion is
> > about IMPLICIT conversion or rvalues to lvalues.
> Yes it is, the issues regarding rvalue/lvalue conversion is not
> the same issues regarding the
On Wednesday, 25 July 2018 at 19:55:50 UTC, Paolo Invernizzi
wrote:
I don't know what vocabulary you are used to consult,
ad hominem attacks is not an argument
Actually, by definition, every bug is made by a programmer that
THINK to know what he is doing... no?
Avoiding burden of proof by
On Wednesday, 25 July 2018 at 17:52:00 UTC, 12345swordy wrote:
On Wednesday, 25 July 2018 at 16:43:38 UTC, Paolo Invernizzi
wrote:
That's an opinion, naturally.
No I am expressing an argument not an opinion.
I don't know what vocabulary you are used to consult, but your
'pointless' it's
On Wed, 25 Jul 2018 at 10:45, Atila Neves via Digitalmars-d
wrote:
>
> On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
> > [...]
> > 3. Scenario depends on introduction of a getter, but any getter
> > property that returns a member by-val is almost certainly a
> > primitive
> > type. A
On Wed, 25 Jul 2018 at 10:45, Atila Neves via Digitalmars-d
wrote:
>
> > ...all that said, we understand that there is value in
> > inhibiting calls with rvalues in some cases. We address this in
> > a very nice way with @disable, which is also nicely symmetrical
> > such that the limitation may
On Wed, 25 Jul 2018 at 04:50, Jim Balter via Digitalmars-d
wrote:
>
> On Wednesday, 25 July 2018 at 08:34:30 UTC, Manu wrote:
> [snip]
>
> > Meanwhile I think we have determined that the presumed
> > practical trouble
> > cases are even less that I suspected up front.
>
> That's surprising; I
On Wednesday, 25 July 2018 at 16:43:38 UTC, Paolo Invernizzi
wrote:
That's an opinion, naturally.
No I am expressing an argument not an opinion.
"let's force the programmer to think about what he is doing,
passing an rvalue by ref"
Nonsense, you have shown no evidence that they don't know
On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
On Sat, 21 Jul 2018 at 00:15, Johannes Loher via Digitalmars-d
wrote:
On Saturday, 21 July 2018 at 05:59:37 UTC, Manu wrote:
> [...]
Let me give a concrete example of one of the situations
Jonathan is describing. Consider the following
On Wednesday, 25 July 2018 at 13:36:38 UTC, 12345swordy wrote:
On Wednesday, 25 July 2018 at 12:40:16 UTC, Paolo Invernizzi
wrote:
That proposal is a 'Syntactic Sugar' feature, that simply hide
what normally need to be explicitly coded: proved a temp
rvalue, pass it to a callable taking ref.
On Wednesday, 25 July 2018 at 12:40:16 UTC, Paolo Invernizzi
wrote:
That proposal is a 'Syntactic Sugar' feature, that simply hide
what normally need to be explicitly coded: proved a temp
rvalue, pass it to a callable taking ref. What you call
'simplification', I call it 'obfuscation'; what
On 26/07/2018 12:40 AM, Paolo Invernizzi wrote:
Just to be clear, I'm also against all the new proposed addition for,
named parameter, new struct initialisation and so on
You'll go giddy once you hear about what I have planned after named
parameters ;)
But seriously tho, just because a
On Wednesday, 25 July 2018 at 08:34:30 UTC, Manu wrote:
With UFCS as a super popular feature of D, 'this' is not really
much of a
special guest at all.
It's just as much the first argument of a function as the first
argument of
*any* UFCS call.
Guido van Rossum has raised an objection on
On Wednesday, 25 July 2018 at 08:34:30 UTC, Manu wrote:
[snip]
It upsets me when people present strong opinions about this who
literally have no horse in the race. This is only really
meaningful, and only affects you if it actually affects you...
It's clearly not important to you, or you
On Saturday, 21 July 2018 at 01:17:40 UTC, Jonathan M Davis wrote:
On Friday, July 20, 2018 18:04:26 Manu via Digitalmars-d wrote:
On Fri, 20 Jul 2018 at 18:02, Manu wrote:
> [...]
>
> I think you're describing now a bug where a function returns
> an lvalue, but it was meant to return an
On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
On Sat, 21 Jul 2018 at 00:15, Johannes Loher via Digitalmars-d
wrote:
On Saturday, 21 July 2018 at 05:59:37 UTC, Manu wrote:
> [...]
Let me give a concrete example of one of the situations
Jonathan is describing. Consider the following
On Wed., 25 Jul. 2018, 12:30 am Paolo Invernizzi via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Wednesday, 25 July 2018 at 02:21:18 UTC, Marco Leise wrote:
> > Am Sat, 21 Jul 2018 19:22:05 +
> > schrieb 12345swordy :
> >
> >> On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo
On Wednesday, 25 July 2018 at 02:21:18 UTC, Marco Leise wrote:
Am Sat, 21 Jul 2018 19:22:05 +
schrieb 12345swordy :
On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi
wrote:
> Frankly speaking, my feeling is that D is becoming a
> horrible mess for the programmer...
> /Paolo
Am Sat, 21 Jul 2018 19:22:05 +
schrieb 12345swordy :
> On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote:
>
> > Frankly speaking, my feeling is that D is becoming a horrible
> > mess for the programmer...
>
> > /Paolo
> How!? Please Explain. You need to demonstrate
On 7/20/18 3:36 PM, Jonathan M Davis wrote:
The reality of the matter is that it's always going to be up to the API
author on some level - e.g. even if the proposed changes were implemented,
there's still the question of whether a function's parameter should be
marked with ref or not, and
Am Fri, 20 Jul 2018 10:33:56 -0600
schrieb Jonathan M Davis :
> On Friday, July 20, 2018 15:50:29 meppl via Digitalmars-d wrote:
> > On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
> > > On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d
> > >
> > > wrote:
> > >>
On Sunday, July 22, 2018 01:53:53 Manu via Digitalmars-d wrote:
> I use the term 'meta' (as in meta-programming) to refer to
> compile-time constructions.
> I don't tend to say "a template", because many problematic
> constructions are compositions, and then consider mixin; not
> 'template's.
> I
On Sunday, 22 July 2018 at 08:53:53 UTC, Manu wrote:
On Sun, 22 Jul 2018 at 01:00, Johannes Loher via Digitalmars-d
wrote:
- Somebody already mentioned this, but this sections sounds
confusing, please find a better wording: "An example may be
some meta that reflects or receives a function
On Sun, 22 Jul 2018 at 01:00, Johannes Loher via Digitalmars-d
wrote:
>
> On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
> > 4. A struct-type getter that returns by-val exhibits this
> > gotcha in a
> > variety of ways; you 'get' the member (a by-val copy), then
> > mutate a
> > member in
On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
4. A struct-type getter that returns by-val exhibits this
gotcha in a
variety of ways; you 'get' the member (a by-val copy), then
mutate a
member in any way, (ie, call a method), and you've accidentally
modified the copy, not the source
On Sat., 21 Jul. 2018, 12:30 pm Johnatune via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> I was for this back when it was only for 'const ref' but that
> somehow changed to just ref. Which I think is a mistake. Yes D's
> const is broken and useless, but I don't think that's a reason to
I was for this back when it was only for 'const ref' but that
somehow changed to just ref. Which I think is a mistake. Yes D's
const is broken and useless, but I don't think that's a reason to
introduce difficult to locate bugs with the addition of this
feature. There's not a simple way to
On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote:
Frankly speaking, my feeling is that D is becoming a horrible
mess for the programmer...
/Paolo
How!? Please Explain. You need to demonstrate evidence instead of
appeal to emotional fallacy by resorting to "feels".
On Saturday, 21 July 2018 at 12:54:28 UTC, JohnB wrote:
On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi
wrote:
Frankly speaking, my feeling is that D is becoming a horrible
mess for the programmer...
I'm starting to think that only a D3, with a lot of thing
reorganised without
On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote:
Frankly speaking, my feeling is that D is becoming a horrible
mess for the programmer...
I'm starting to think that only a D3, with a lot of thing
reorganised without the obsession of breaking changes can safe
that beautiful
Thanks a lot, Manu, I'm a huge fan of this.
Wrt. binding rvalues to mutable refs, we could introduce
something like `-transition=rval_to_mutable_ref` to have the
compiler list all matching call sites.
Wrt. `auto ref`, I'd very much like to see its semantics change
to 'pass this argument in
On Friday, 20 July 2018 at 23:19:08 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 16:39:46 UTC, Dukc wrote:
How so? It could be made it act exactly as if the temporary
was made just before the function call, meaning the lifetime
would end at the end of current scope.
... which is
On Saturday, 21 July 2018 at 05:40:24 UTC, Nicholas Wilson wrote:
It is not just the avoiding copying, if it were I'm not sure
I'd support it. For me the greatest benefit is the increase in
readability due to not having useless temporaries everywhere in
ref heavy code (that may not be under
On Sat, 21 Jul 2018 at 00:15, Johannes Loher via Digitalmars-d
wrote:
>
> On Saturday, 21 July 2018 at 05:59:37 UTC, Manu wrote:
> > [...]
>
> Let me give a concrete example of one of the situations Jonathan
> is describing. Consider the following code:
>
>
> struct Secret
> {
> public:
>
On Saturday, 21 July 2018 at 07:10:51 UTC, Johannes Loher wrote:
[...]
By the way, this does not mean I am totally against DIP 1016. It
has a lot of benefits in my opinion. But I also think that
Jonathan has a very valid point which definitely needs to be
considered.
On Saturday, 21 July 2018 at 05:59:37 UTC, Manu wrote:
[...]
Let me give a concrete example of one of the situations Jonathan
is describing. Consider the following code:
struct Secret
{
public:
string key;
}
/* ... */
genrateRandomKey(ref string key) {
key = /* some code to
On Fri, 20 Jul 2018 at 22:45, Nicholas Wilson via Digitalmars-d
wrote:
>
> On Saturday, 21 July 2018 at 04:09:25 UTC, Jonathan M Davis wrote:
> > Honestly, I think we're just coming from points of view that
> > are too different. IMHO, the core use case for ref is for a
> > function to mutate an
On Saturday, 21 July 2018 at 04:09:25 UTC, Jonathan M Davis wrote:
Honestly, I think we're just coming from points of view that
are too different. IMHO, the core use case for ref is for a
function to mutate an argument and have that result progagate
to the argument,
I think the critical
On Friday, July 20, 2018 19:13:00 Manu via Digitalmars-d wrote:
> I can't see how this is a compelling reason to dismiss all the
> advantages of this DIP in favour of keeping the current semantic.
Honestly, I think we're just coming from points of view that are too
different. IMHO, the core use
On Fri, 20 Jul 2018 at 18:17, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Friday, July 20, 2018 18:04:26 Manu via Digitalmars-d wrote:
> > On Fri, 20 Jul 2018 at 18:02, Manu wrote:
> > > [...]
> > >
> > > I think you're describing now a bug where a function returns an
> > > lvalue, but it
On Friday, July 20, 2018 18:04:26 Manu via Digitalmars-d wrote:
> On Fri, 20 Jul 2018 at 18:02, Manu wrote:
> > [...]
> >
> > I think you're describing now a bug where a function returns an
> > lvalue, but it was meant to return an rvalue.
>
> Sorry, wrong way around! I meant to say:
> I think
On Fri, 20 Jul 2018 at 18:02, Manu wrote:
>
> [...]
>
> I think you're describing now a bug where a function returns an
> lvalue, but it was meant to return an rvalue.
Sorry, wrong way around! I meant to say:
I think you're describing now a bug where a function returns an
rvalue, but it was
On Fri, 20 Jul 2018 at 17:33, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Saturday, July 21, 2018 00:10:09 Nicholas Wilson via Digitalmars-d wrote:
> > So this problem is restricted output range @properties that
> > somehow don't return by ref, aren't intended to be used after
> > having
On Saturday, July 21, 2018 00:10:09 Nicholas Wilson via Digitalmars-d wrote:
> So this problem is restricted output range @properties that
> somehow don't return by ref, aren't intended to be used after
> having data written to them _and_ aren't singleton like?
It's a problem for any function
On Friday, 20 July 2018 at 23:35:46 UTC, Jonathan M Davis wrote:
On Friday, July 20, 2018 14:35:57 Manu via Digitalmars-d wrote:
Comparatively rare? It's exactly what most functions using
output ranges need to do. For many output ranges, if the
function copies the range instead of copying,
On Friday, July 20, 2018 14:35:57 Manu via Digitalmars-d wrote:
> > > Their currently behaviour is mostly wrong, and the exact thing I'm
> > > trying to fix though.
> >
> > Why would the current behviour be mostly wrong? If the purpose of using
> > ref is to accept the current value of a variable
On Friday, 20 July 2018 at 16:39:46 UTC, Dukc wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or
On Fri, 20 Jul 2018 at 12:51, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Friday, July 20, 2018 12:21:42 Manu via Digitalmars-d wrote:
> > I think disabling it is going to be the overwhelmingly niche case, but
> > it's good that you can still do it and be satisfied if that's what you
> >
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
Yay! Thank you Manu for taking
On Fri, 20 Jul 2018 at 12:36, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Friday, July 20, 2018 11:50:41 Manu via Digitalmars-d wrote:
> > > I am completely against allowing ref to accept rvalues without some sort
> > > of attribute indicating that it should be allowed to (e.g. @rvalue
> > >
On Friday, July 20, 2018 12:21:42 Manu via Digitalmars-d wrote:
> I think disabling it is going to be the overwhelmingly niche case, but
> it's good that you can still do it and be satisfied if that's what you
> want to do.
>
> Can you link me to a single line of your own code where you've used
>
On Friday, July 20, 2018 11:50:41 Manu via Digitalmars-d wrote:
> > I am completely against allowing ref to accept rvalues without some sort
> > of attribute indicating that it should be allowed to (e.g. @rvalue
> > ref).
> I sincerely hope you're in the minority :(
>
> > Allowing ref to accept
On Fri, 20 Jul 2018 at 11:05, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Friday, July 20, 2018 17:25:25 Daniel N via Digitalmars-d wrote:
> > On Friday, 20 July 2018 at 17:02:04 UTC, Jonathan M Davis wrote:
> > > On Friday, July 20, 2018 16:42:54 aliak via Digitalmars-d wrote:
> > >> On
On Fri, 20 Jul 2018 at 06:21, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1016, "ref T accepts r-values":
> >
> >
On Fri, 20 Jul 2018 at 05:40, Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 7/20/18 1:16 AM, Mike Parker wrote:
> > This is the feedback thread for the first round of Community Review for
> > DIP 1016, "ref T accepts r-values":
> >
> >
On Friday, July 20, 2018 17:25:25 Daniel N via Digitalmars-d wrote:
> On Friday, 20 July 2018 at 17:02:04 UTC, Jonathan M Davis wrote:
> > On Friday, July 20, 2018 16:42:54 aliak via Digitalmars-d wrote:
> >> On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis
> >>
> >> But as for a UDA,
On Fri, 20 Jul 2018 at 04:50, Seb via Digitalmars-d
wrote:
>
> On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1016, "ref T accepts r-values":
> >
> >
On Fri, 20 Jul 2018 at 03:55, Petar via Digitalmars-d
wrote:
>
> On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1016, "ref T accepts r-values":
> >
> >
On Fri, 20 Jul 2018 at 02:05, Dukc via Digitalmars-d
wrote:
>
> On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1016, "ref T accepts r-values"
>
> I'd prefer a solution which allows one to make an
On Fri, 20 Jul 2018 at 03:10, Dgame via Digitalmars-d
wrote:
>
> On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
> > On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
> >> appending something (like .byRef or byRef!long, the latter
> >> making an implicit type conversion)
> >
>
On Friday, 20 July 2018 at 17:02:04 UTC, Jonathan M Davis wrote:
On Friday, July 20, 2018 16:42:54 aliak via Digitalmars-d wrote:
On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis
But as for a UDA, maybe @implicit from the copy constructor
DIP can be reused here?
void f(@implicit
On Fri, 20 Jul 2018 at 02:25, Bastiaan Veelo via Digitalmars-d
wrote:
>
> On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1016, "ref T accepts r-values":
> >
> >
On Friday, July 20, 2018 16:42:54 aliak via Digitalmars-d wrote:
> On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
> > On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d
> >
> > wrote:
> >> [...]
> >
> > I am completely against allowing ref to accept rvalues without
>
On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d
wrote:
[...]
I am completely against allowing ref to accept rvalues without
some sort of attribute indicating that it should be allowed to
(e.g. @rvalue ref).
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or allocates with no way to deallocate (bad).
How so? It
On Friday, 20 July 2018 at 09:24:19 UTC, Bastiaan Veelo wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
Thanks for the effort to make it... I believe Manu will be
pleased.
Manu is the one who wrote the DIP :-)
Though it was Mike :-)
On Friday, July 20, 2018 15:50:29 meppl via Digitalmars-d wrote:
> On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
> > On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d
> >
> > wrote:
> >> ...
> >
> > ...
> > Allowing ref to accept rvalues goes completely against the
On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d
wrote:
...
...
Allowing ref to accept rvalues goes completely against the idea
that ref is for passing an object so that it can be mutated and
have its result
On Friday, July 20, 2018 15:18:33 Daniel N via Digitalmars-d wrote:
> On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
> > auto ref was already introduced to solve this problem. The
> > problem of course is that it requires that the function be
> > templated, and while that's often
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
All review-related feedback on
On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
auto ref was already introduced to solve this problem. The
problem of course is that it requires that the function be
templated, and while that's often desirable, it's not always a
viable option (e.g. it doesn't work with
On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d wrote:
> This is the feedback thread for the first round of Community
> Review for DIP 1016, "ref T accepts r-values":
>
> https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd
> 7/DIPs/DIP1016.md
>
> All
On 7/20/18 1:16 AM, Mike Parker wrote:
This is the feedback thread for the first round of Community Review for
DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
All review-related feedback on and discussion of
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
Thanks in advance to all who participate.
"It has been noted that is it possible"
switch: it <-> is
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
All review-related feedback on
On Friday, 20 July 2018 at 10:43:54 UTC, Dgame wrote:
On Friday, 20 July 2018 at 10:31:48 UTC, Seb wrote:
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson
wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
All review-related feedback on
On Friday, 20 July 2018 at 10:31:48 UTC, Seb wrote:
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or
On Friday, 20 July 2018 at 08:12:00 UTC, Dominikus Dittes Scherkl
wrote:
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or allocates with no way to deallocate (bad).
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
Thanks for the effort to make it... I believe Manu will be
pleased.
Manu is the one who wrote the DIP :-)
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
The only difficulty I had was
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values"
I'd prefer a solution which allows one to make an invisible temp
manually without making a new statement or a new symbol name.
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
+1
The DIP reduces bloat,
88 matches
Mail list logo
