On Friday, 28 April 2017 at 18:05:41 UTC, Steven Schveighoffer
wrote:
On 4/28/17 12:56 PM, Ola Fosheim Grøstad wrote:
Isn't that an odd stance given that "struct" is supposed to be
a value
type?
Not really, but thanks for asking.
Well, it counters the very definition of a value... I guess
On 4/28/17 12:56 PM, Ola Fosheim Grøstad wrote:
On Thursday, 27 April 2017 at 12:28:38 UTC, Steven Schveighoffer wrote:
My solution would be to push the duplication onto the user. I'm not a
fan of implicit copying. It's also wasteful in the case of immutable
data.
Isn't that an odd stance
On Thursday, 27 April 2017 at 12:28:38 UTC, Steven Schveighoffer
wrote:
My solution would be to push the duplication onto the user. I'm
not a fan of implicit copying. It's also wasteful in the case
of immutable data.
Isn't that an odd stance given that "struct" is supposed to be a
value
On 4/26/17 8:17 PM, Stanislav Blinov wrote:
On Wednesday, 26 April 2017 at 13:38:59 UTC, Steven Schveighoffer wrote:
If you want to duplicate const data, but just shallow-copy mutable
data, you are correct in that you need two separate constructors, and
inout doesn't come into play.
That's
On Wednesday, 26 April 2017 at 13:38:59 UTC, Steven Schveighoffer
wrote:
~this()
{
data.destroy();
}
Don't do this. It's not a good idea, since data could be
invalid at this point. In this case, destroy does nothing (it
just sets the array to null), so I would just
On 4/26/17 2:17 AM, Stanislav Blinov wrote:
On Wednesday, 26 April 2017 at 02:19:03 UTC, Manu wrote:
Right, yeah I see. So, basically, you admit that it is required to
have 3 overloads; foo(X), foo(ref X) and foo(ref const X), in the
event that I want to avoid needlessly copying X prior to
On Wednesday, 26 April 2017 at 02:19:03 UTC, Manu wrote:
Right, yeah I see. So, basically, you admit that it is required
to have 3 overloads; foo(X), foo(ref X) and foo(ref const X),
in the event that I want to avoid needlessly copying X prior to
constructing from it in the non-const case...
On 25 April 2017 at 14:17, Stanislav Blinov via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 25 April 2017 at 01:59:55 UTC, Manu wrote:
>
> Ah crap, I somehow missed the single-argument move() function.
>>
>> Okay, so this pattern is definitely reliable? I haven't seen it
On Tuesday, 25 April 2017 at 08:53:22 UTC, Stanislav Blinov wrote:
On Tuesday, 25 April 2017 at 07:58:43 UTC, Jack Applegame wrote:
On Monday, 24 April 2017 at 18:48:00 UTC, Stanislav Blinov
wrote:
Suddenly, we can't copy the pointer, or at least make a
shallow copy of it, without violating
On Tuesday, 25 April 2017 at 07:58:43 UTC, Jack Applegame wrote:
On Monday, 24 April 2017 at 18:48:00 UTC, Stanislav Blinov
wrote:
Suddenly, we can't copy the pointer, or at least make a
shallow copy of it, without violating const, and the latter is
UB.
Because transitive const/immutable is
On Monday, 24 April 2017 at 18:48:00 UTC, Stanislav Blinov wrote:
Suddenly, we can't copy the pointer, or at least make a shallow
copy of it, without violating const, and the latter is UB.
Because transitive const/immutable is shit. And that shit had to
introduce another shit - Rebindable. D
On Tuesday, 25 April 2017 at 01:59:55 UTC, Manu wrote:
Ah crap, I somehow missed the single-argument move() function.
Okay, so this pattern is definitely reliable? I haven't seen it
clearly documented anywhere that this is the prescribed
pattern, and it's come up on stack overflow a few
On 25 April 2017 at 08:46, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 04/24/2017 04:23 PM, ag0aep6g wrote:
>
>> On 04/24/2017 08:48 PM, Stanislav Blinov wrote:
>>
>>> Speaking of const violation and UB, std.algorithm.mutation.move seems to
>>> violate const
On 04/24/2017 07:13 PM, Stanislav Blinov wrote:
On Monday, 24 April 2017 at 22:46:18 UTC, Andrei Alexandrescu wrote:
On 04/24/2017 04:23 PM, ag0aep6g wrote:
On 04/24/2017 08:48 PM, Stanislav Blinov wrote:
Speaking of const violation and UB, std.algorithm.mutation.move
seems to
violate const
On Monday, 24 April 2017 at 22:46:18 UTC, Andrei Alexandrescu
wrote:
On 04/24/2017 04:23 PM, ag0aep6g wrote:
On 04/24/2017 08:48 PM, Stanislav Blinov wrote:
Speaking of const violation and UB,
std.algorithm.mutation.move seems to
violate const without remorse:
Yup. Even in @safe code, which
On 04/24/2017 04:23 PM, ag0aep6g wrote:
On 04/24/2017 08:48 PM, Stanislav Blinov wrote:
Speaking of const violation and UB, std.algorithm.mutation.move seems to
violate const without remorse:
Yup. Even in @safe code, which is a bug.
https://issues.dlang.org/show_bug.cgi?id=15315
Should fail
On 04/24/2017 08:48 PM, Stanislav Blinov wrote:
Speaking of const violation and UB, std.algorithm.mutation.move seems to
violate const without remorse:
Yup. Even in @safe code, which is a bug.
https://issues.dlang.org/show_bug.cgi?id=15315
On 4/24/17 2:48 PM, Stanislav Blinov wrote:
On Monday, 24 April 2017 at 15:19:29 UTC, Manu wrote:
If you're going to pinch the guts of rvalue arguments, then this needs to
be 100% reliable.
This needs to be aggressively unit-tested, and probably documented that
this is the official pattern for
On Monday, 24 April 2017 at 15:19:29 UTC, Manu wrote:
If you're going to pinch the guts of rvalue arguments, then
this needs to
be 100% reliable.
This needs to be aggressively unit-tested, and probably
documented that
this is the official pattern for rvalue construction/assignment
On 25 April 2017 at 00:00, Steven Schveighoffer via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote:
>
> I wonder if this overload set could be made to work such that it is
>> certain that the non-ref overload is only called with rvalues;
On Monday, 24 April 2017 at 13:18:41 UTC, Manu wrote:
I've done that too, but that's a seriously shit solution. You
didn't comment on any of my actual questions ;)
It answered your first question :)
On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote:
struct X {}
struct Y {
this(auto ref X x)
{
static if (__traits(isRef, x))
{
// x is lvalue, copy construct
}
else
{
// x MUST be rvalue(?), move construct
// does this pattern require that I
On Monday, 24 April 2017 at 14:00:33 UTC, Steven Schveighoffer
wrote:
On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote:
I wonder if this overload set could be made to work such that
it is
certain that the non-ref overload is only called with rvalues;
ie, given
this ambiguous call, ref is
On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote:
I wonder if this overload set could be made to work such that it is
certain that the non-ref overload is only called with rvalues; ie, given
this ambiguous call, ref is preferred for lvalues. rval can not call
ref, therefore must resolve to
On 24 April 2017 at 18:36, Ola Fosheim Grøstad via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote:
>
>> Now, I'm not saying that rval references are the only solution here, just
>> that I can overload the construction from an X for the
On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote:
Now, I'm not saying that rval references are the only solution
here, just that I can overload the construction from an X for
the rvalue and non-rvalue case, which is what I want...
What I've done in the past is simply to create a
On Monday, 24 April 2017 at 05:00:13 UTC, rikki cattermole wrote:
There is[0] but idk how close it is to std:move and the likes.
[0] http://dlang.org/phobos/std_algorithm_mutation.html#.move
std::move doesn't do anything, it is just a type-cast.
Yeah, that's not the same thing at all.
On 24 April 2017 at 15:00, rikki cattermole via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> There is[0] but idk how close it is to std:move and the likes.
>
> [0] http://dlang.org/phobos/std_algorithm_mutation.html#.move
>
There is[0] but idk how close it is to std:move and the likes.
[0] http://dlang.org/phobos/std_algorithm_mutation.html#.move
Are there any known solutions to perform efficient move construction in D?
D's pretty good at doing moves at all the right times, but with a serious
limitation compared to C++ that the type must be an exact match.
Consider this C++; really bad example, but just to illustrate:
struct X {
30 matches
Mail list logo
