On Tuesday, 14 November 2023 at 13:58:17 UTC, Paul Backus wrote:
On Tuesday, 14 November 2023 at 13:41:32 UTC, Steven
Schveighoffer wrote:
```
Error: copy constructor `testinoutctor.S1.this(ref const(S1)
s) const` is not callable using argument types `(const(S1))`
```
I'm not sure what
On Tuesday, 14 November 2023 at 16:51:07 UTC, Paul Backus wrote:
There's no assignment. The value is constructed in-place, in
`ss2`'s memory.
The reason the compiler allows you to construct a `const(S2)`
value inside of an `S2` variable is that `const(S2)` implicitly
converts to `S2`.
On
On Tuesday, 14 November 2023 at 13:58:17 UTC, Paul Backus wrote:
It's easier to see if you compare the actual and expected
argument lists side-by-side
Expected: (ref const(S1) s) const
Actual: (const(S1) )
^
Mismatched 'th
...
s2.__ctor(&answer);
// ...then this could happen
*s2.p = 12345;
}
```
Thanks for this explanation, it all makes perfect sense.
Regarding implicit qualifier conversion: in my code, S2 has a
copy constructor, so it takes a "ref inout S2" as input. Since
the copy con
On Tuesday, 14 November 2023 at 14:36:57 UTC, dhs wrote:
Just to clarify some more: isn't "s1 = ss1" similar to
something like:
```d
const(S1) s1;
S1 ss1; // ss1 is now S1.init
S1_copy_construct_const_in_const_out(ss1, s1);
```
If this is the case, the compile error is expected, bu
On Tuesday, 14 November 2023 at 14:36:57 UTC, dhs wrote:
Just to clarify some more: isn't "s1 = ss1" similar to
I meant "ss1 = s1" here, sorry.
On Tuesday, 14 November 2023 at 13:58:17 UTC, Paul Backus wrote:
On Tuesday, 14 November 2023 at 13:41:32 UTC, Steven
The error is saying that the copy constructor expects a `const`
`this` argument, but you're passing a mutable `this` argument.
Thanks you both very much for answ
On Tuesday, 14 November 2023 at 13:41:32 UTC, Steven
Schveighoffer wrote:
```
Error: copy constructor `testinoutctor.S1.this(ref const(S1) s)
const` is not callable using argument types `(const(S1))`
```
I'm not sure what this means. There shouldn't be a copy being
made here, as th
On Tuesday, 14 November 2023 at 08:50:34 UTC, dhs wrote:
```d
struct S2
{
this(ref inout S2 s) inout { writeln("copy"); }
int i;
}
void test()
{
const(S1) s1;
S1 ss1 = s1; // error, ss1 not qualified as const
const(S2) s2;
S2 ss2 = s2; // fine, why?
}
```
Isn't "inout"
does not fail because the type is implicitly
convertible to non-const (a const int can be converted to a
mutable int). Change `i` to `int *` and it will fail.
IMO, the first should succeed as well. And I will note that the
error looks different from what you say:
```
Error: copy constructor `test
On Tuesday, 14 November 2023 at 09:07:24 UTC, Alexandru Ermicioi
wrote:
Seems like it isn't called at all, your copy constructor with
inout. Could be a bug.
My assumption is that default copy constructors are generated
alongside inout one, and then picked up for your initialization
in
On Tuesday, 14 November 2023 at 08:50:34 UTC, dhs wrote:
In other words: why doesn't ss2=s2 fail here?
Thanks,
dhs
Seems like it isn't called at all, your copy constructor with
inout. Could be a bug.
My assumption is that default copy constructors are generated
alongside inou
Hello D experts,
I have a question regarding inout in struct copy constructors.
From the spec:
"The copy constructor can be overloaded with different qualifiers
applied to the parameter (copying from a qualified source) or to
the copy constructor itself (copying to a qualified destin
erestingly, even using `to!string` the copy-constructor works
extra +4 times! I think there will be performance losses if
`write()` is used unconsciously everywhere! Although this way, it
kisses with ctor +1 times :)
SDB@79
On 6/5/22 14:57, Ali Çehreli wrote:
> struct Foo {
>Foo dup() {
> auto result = Foo(this.payload);
> // ...
> return result;
>}
> }
>
> In that case, the "named return value optimization" (NRVO) would be
> applied and the object would still be moved to 'x'.
I am wrong ther
On 6/5/22 14:39, Ali Çehreli wrote:
> Actually, both are copy construction:
I am wrong there. I did confuse myself.
>Foo one = Foo(1), two = 2;
As my rewrite shows, they are both construction with an int:
>auto one = Foo(1);
>auto two = Foo(2);
Ali
On 6/5/22 11:43, Alain De Vos wrote:
> Does Foo(3) lives on the stack or the heap ?
It depends.
> there is a
> conversion.
Suche conversions are called "construction" in D.
> And what happes with
> Foo[3] arr = [one, two, Foo(3)];
Foo[3] is a static array. Static arrays are value types. Thei
On 6/5/22 12:00, Salih Dincer wrote:
> On Sunday, 5 June 2022 at 18:43:19 UTC, Alain De Vos wrote:
>> Does Foo(3) lives on the stack or the heap ?
I depends. I will respond to your other message.
> Definitely not stack because that's what happens when the new operator
> is used. Article 14.3: ht
On 6/5/22 14:04, Alain De Vos wrote:
> Could it be the copy constructor is only called during assignments (like
> C++).
The assignment operator is used during assignments both in C++ and D.
A confusion comes from the fact that construction uses the same operator
as assignment:
Could it be the copy constructor is only called during
assignments (like C++).
And for one, two there is an explicit assignment.
But not for three where there is a conversion ?
On Sunday, 5 June 2022 at 18:43:19 UTC, Alain De Vos wrote:
Does Foo(3) lives on the stack or the heap ?
Definitely not stack because that's what happens when the new
operator is used. Article 14.3:
https://dlang.org/spec/struct.html#intro
SDB@79
On Sunday, 5 June 2022 at 18:50:13 UTC, Salih Dincer wrote:
On Sunday, 5 June 2022 at 15:45:17 UTC, Salih Dincer wrote:
Hi,
Let be the structure Foo that wraps an int pointer. Let's
setup Foo in 3 different ways:
1. Foo one = Foo(1);
2. Foo two = 2;
3. [ Foo(3) ];
There is a fourth possibil
On Sunday, 5 June 2022 at 15:45:17 UTC, Salih Dincer wrote:
Hi,
Let be the structure Foo that wraps an int pointer. Let's setup
Foo in 3 different ways:
1. Foo one = Foo(1);
2. Foo two = 2;
3. [ Foo(3) ];
There is a fourth possibility:
```d
int[] arr = [ one, two, Foo(3), *(new Foo(4)) ];
``
I don't know the answer. But some questions come to my mind.
Does Foo(3) lives on the stack or the heap ?
There is also no assignment from Foo to Foo for Foo(3), there is
a conversion.
And what happes with
Foo[3] arr = [one, two, Foo(3)];
Foo[] arr= [one, two, Foo(3)];
and
Foo x=Foo(3).dup()
Hi,
Let be the structure Foo that wraps an int pointer. Let's setup
Foo in 3 different ways:
1. Foo one = Foo(1);
2. Foo two = 2;
3. [ Foo(3) ];
Pretty clean, right?
So why it's not run copy-constructor in 3? Also, when we write to
the screen with writeln(), why four
On Wednesday, 12 January 2022 at 08:04:19 UTC, vit wrote:
Hello, I have this code:
```d
[...]
run.dlang.io has old version of dmd-beta/dmd-nightly with bug
("end");
}
```
When is this code compiled with 2.098.1 then it print:
```
Error: Cannot define both an rvalue constructor and a copy
constructor for `struct Foo`
Template instance `__ctor!(Foo)` creates a rvalue
constructor for `struct Foo`
Error: template instance `onl
On Thursday, 30 December 2021 at 01:04:10 UTC, Ali Çehreli wrote:
The second item in the documentation mentions "any number of
default parameters" when describing copy constructor syntax:
https://dlang.org/spec/struct.html#struct-copy-constructor
1) I can't figure out how to
On Thursday, 30 December 2021 at 04:42:06 UTC, Tejas wrote:
On Thursday, 30 December 2021 at 01:04:10 UTC, Ali Çehreli
wrote:
The second item in the documentation mentions "any number of
default parameters" when describing copy constructor syntax:
https://dlang.org/spec/struct.h
On Thursday, 30 December 2021 at 01:04:10 UTC, Ali Çehreli wrote:
The second item in the documentation mentions "any number of
default parameters" when describing copy constructor syntax:
https://dlang.org/spec/struct.html#struct-copy-constructor
1) I can't figure out how to
mples
look like this:
A r1;
const(A) r2;
immutable(A) r3;
// All call the same copy constructor because `inout` acts
like a wildcard
immutable(A) a = r1;
immutable(A) b = r2;
immutable(A) c = r3;
On 12/29/21 5:14 PM, Paul Backus wrote:
Therefore, when you write your own copy constructors, you should always
use `inout` if possible, so that compiler-generated copy constructors
will be able to copy instances of your struct that appear as members of
other structs.
Excellent point. I noti
When the compiler generates a copy constructor for you, it always
qualifies both the source and destination objects with `inout`:
https://dlang.org/spec/struct.html#implicit-copy-constructors
Therefore, when you write your own copy constructors, you should
always use `inout` if possibl
The second item in the documentation mentions "any number of default
parameters" when describing copy constructor syntax:
https://dlang.org/spec/struct.html#struct-copy-constructor
1) I can't figure out how to use those extra parameters. For example, I
can't find a spec
On Friday, 19 November 2021 at 14:22:07 UTC, Paul Backus wrote:
When you pass a struct instance to a function by value, or
return a struct instance from a function by value, a copy is
made, and the copy constructor is called.
Your `opAssign` takes `rhs` by value, and returns a `str` by
On Friday, 19 November 2021 at 14:05:40 UTC, rempas wrote:
So, when I assign the value of the variable "name" in the
"other_name", first it will call the copy constructor, then it
will call the assignment constructor and then it will call the
copy constructor again. Why
t char* val) {
printf("Debug: Called this(const char* val)\n");
this._val = cast(char*)val;
this._count = cast(uint*)pureMalloc(4);
*this._count = 0;
this._cap = 0;
this._len = strlen(val);
}
// Copy constructor
this(ref return scope str rhs) {
printf("
On Saturday, 6 November 2021 at 17:24:07 UTC, tchaloupka wrote:
When built with `-betterC` switch (dmd as ldc2 works with it).
I get just:
```
Error: `TypeInfo` cannot be used with -betterC
```
Well imagine getting this useful info in a large codebase :/
Looks like https://issues.dlang.org/sh
9e2567ecacd5fab/src/dmd/e2ir.d#L2606
So it somehow tries to generate `_d_arrayctor` for the static
array.
I've tried to add `= void` to the array, but it doesn't help.
Is it a bug (probably is) and are there any workaround for this?
If I remove copy constructor or destructor form `Foo`,
On 7/10/20 3:31 AM, psycha0s wrote:
On Thursday, 9 July 2020 at 22:18:59 UTC, Steven Schveighoffer wrote:
Looking at the generated AST, it's because the compiler is adding an
auto-generated opAssign, which accepts a Foo by value. It is that
object that is being created and destroyed.
Is there
On Thursday, 9 July 2020 at 22:18:59 UTC, Steven Schveighoffer
wrote:
Looking at the generated AST, it's because the compiler is
adding an auto-generated opAssign, which accepts a Foo by
value. It is that object that is being created and destroyed.
Is there a reason the autogenerated opAssign
On 7/9/20 6:08 PM, psycha0s wrote:
import std.stdio;
struct Foo {
int value;
this(int n)
{
value = n;
writeln("constuctor ", &this);
}
~this()
{
writeln("destuctor ", &this);
}
this(ref return scope Foo other)
{
I just didn't expect that the address of a "this" reference may
change.
I was learning copy constructors and got a really weird result.
It looks like a copy constructor and a destuctor of two unknown
objects are called. Could somebody please explain it to me?
import std.stdio;
struct Foo {
int value;
this(int n)
{
value
On 6/23/20 9:47 AM, Sebastiaan Koppe wrote:
On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
I'm also wondering what's the motivation behind supporting
non-copyable ranges, and whether it's worth the effort and inevita
On Tuesday, 23 June 2020 at 03:52:23 UTC, Jonathan M Davis wrote:
It is extremely common to wrap ranges in other ranges (and in
fact, you basically have to in order to have lazy ranges). That
really doesn't work very well - if at all - if you can't copy
the range. It might be possible with a
On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
I'm also wondering what's the motivation behind supporting
non-copyable ranges, and whether it's worth the effort and
inevitable complications to support it if it's a ra
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
On Tue, Jun 23, 2020 at 03:25:55AM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis
wrote:
> We'd need some major redesigning to make uncopyable ranges
> work, and person
On Tuesday, 23 June 2020 at 03:52:23 UTC, Jonathan M Davis wrote:
On Monday, June 22, 2020 9:25:55 PM MDT Stanislav Blinov via
Digitalmars-d- learn wrote:
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis
wrote:
> As things stand, uncopyable ranges aren't really a thing,
> and common r
On Tue, Jun 23, 2020 at 03:25:55AM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
>
> > As things stand, uncopyable ranges aren't really a thing, and common
> > range idiomns rely on ranges being copyable.
>
> Which idio
On Monday, June 22, 2020 9:25:55 PM MDT Stanislav Blinov via Digitalmars-d-
learn wrote:
> On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
> > As things stand, uncopyable ranges aren't really a thing, and
> > common range idiomns rely on ranges being copyable.
>
> Which idioms are
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
As things stand, uncopyable ranges aren't really a thing, and
common range idiomns rely on ranges being copyable.
Which idioms are those? I mean, genuine idioms, not design flaws
like e.g. references.
We'd need some major red
On Mon, Jun 22, 2020 at 08:53:22PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> Exactly. It's because of issues like this that generic, range-based
> functions need to be tested with a variety of range types - including
> reference types. Without that, bugs are routinely missed.
On Monday, June 22, 2020 3:33:08 PM MDT H. S. Teoh via Digitalmars-d-learn
wrote:
> On Mon, Jun 22, 2020 at 09:11:07PM +, Stanislav Blinov via Digitalmars-
d-learn wrote:
> > That is not true. Copying of forward ranges is absolutely fine. It's
> > what the current `save()` primitive is suppose
On Monday, June 22, 2020 3:11:07 PM MDT Stanislav Blinov via Digitalmars-d-
learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
> > You're unlikely to find much range-based code that does that
> > and there really isn't much point in doing that. Again, copying
> > isn't
On Monday, June 22, 2020 3:38:02 PM MDT Paul Backus via Digitalmars-d-learn
wrote:
> On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
> > Jonathan is coming from the POV of generic code. The problem
> > with move leaving the original range in its .init state isn't
> > so much that it wi
On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
Don't be shocked when you find out how many Phobos ranges have
.init states that are invalid (e.g., non-empty, but .front and
.popFront will crash / return invalid values).
Which ones?
Jonathan is coming from the POV of generic code.
On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
Jonathan is coming from the POV of generic code. The problem
with move leaving the original range in its .init state isn't
so much that it will crash or anything (even though as you said
that does indicate a flaw in the range's imple
On Monday, June 22, 2020 3:10:28 PM MDT kinke via Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
> > [...]
>
> That's why I put the struct in parantheses. Moving a class ref
> makes hardly any sense, but I've also never written a *class* to
> represent
On Mon, Jun 22, 2020 at 09:11:07PM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
[...]
> > And moving doesn't fix anything, since the original variable is
> > still there (just in its init state, which would still be inval
On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
You're unlikely to find much range-based code that does that
and there really isn't much point in doing that. Again, copying
isn't the problem. It's using the original after making the
copy that's the problem.
Copy *is* the pro
On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
[...]
That's why I put the struct in parantheses. Moving a class ref
makes hardly any sense, but I've also never written a *class* to
represent a range. Moving is the no-brainer solution for
transferring ownership of struct ran
On Monday, June 22, 2020 1:41:34 PM MDT kinke via Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 19:03:44 UTC, Jonathan M Davis wrote:
> > in practice, that means that generic code cannot use a range
> > once it's been copied
>
> Translating to a simple rule-of-thumb: never copy a (struct)
On Monday, 22 June 2020 at 19:03:44 UTC, Jonathan M Davis wrote:
in practice, that means that generic code cannot use a range
once it's been copied
Translating to a simple rule-of-thumb: never copy a (struct)
range, always move.
On Monday, June 22, 2020 10:59:45 AM MDT kinke via Digitalmars-d-learn wrote:
> If copying a range is considered to be generally unsafe and a
> common pitfall (vs. the save() abomination), maybe range-foreach
> shouldn't allow any lvalue ranges in the 1st place, thus not
> making any copies and for
On Monday, 22 June 2020 at 16:25:11 UTC, Jonathan M Davis wrote:
The reason that foreach copies the range is simply due to how
the code is lowered. e.g.
foreach(e; range)
{
}
essentially becomes
for(auto r = range; !r.empty; r.popFront())
{
auto e = r.front;
}
On Sunday, June 21, 2020 2:25:37 PM MDT kinke via Digitalmars-d-learn wrote:
> A foreach over a custom range makes an initial copy, so that the
> original range is still usable after the foreach (not empty).
No, it's not so that the range will be useable afterwards. In fact, for
generic code, you
A foreach over a custom range makes an initial copy, so that the
original range is still usable after the foreach (not empty).
https://pastebin.com/BYcRN8T2
why called copy constructor for ref Range struct type in foreach ?
```
struct MyRange {
private int current_row = 0;
private int rows_count = 5;
@disable this(this); // <===
bool empty () { return current_row == rows_count; }
int fr
On 3/9/20 11:49 AM, mark wrote:
On Monday, 9 March 2020 at 14:45:15 UTC, Steven Schveighoffer wrote:
On 3/9/20 9:23 AM, mark wrote:
I have this struct:
[snip]
I would name it dup instead of copy for consistency with D. A copy
constructor is pretty heavy for a struct to do a complete
On Monday, 9 March 2020 at 14:45:15 UTC, Steven Schveighoffer
wrote:
On 3/9/20 9:23 AM, mark wrote:
I have this struct:
[snip]
I would name it dup instead of copy for consistency with D. A
copy constructor is pretty heavy for a struct to do a complete
duplication of the AA. You should have
ame] = deb.copy; // YYY
deb.clear;
}
(1) XXX Is there a nicer way to copy an AA?
aa.dup. However, this isn't going to work in a const member function
(though technically there shouldn't be anything wrong with it).
(2) YYY Is there a nicer way to copy a struct? Use a copy construct
s there a nicer way to copy an AA?
(2) YYY Is there a nicer way to copy a struct? Use a copy
constructor or implement a dup or idup?
> Either way, generic code should never be using a range after
> it's been copied, and copying is a key part of how
> idiomatic, range-based code works in D.
OK. Thanks for instructions. I shall give it a try.
On Sunday, February 16, 2020 12:22:01 PM MST Paul Backus via Digitalmars-d-
learn wrote:
> On Sunday, 16 February 2020 at 18:11:11 UTC, Jonathan M Davis
>
> wrote:
> > Either way, generic code should never be using a range after
> > it's been copied, and copying is a key part of how idiomatic,
> >
On Sunday, 16 February 2020 at 18:11:11 UTC, Jonathan M Davis
wrote:
Either way, generic code should never be using a range after
it's been copied, and copying is a key part of how idiomatic,
range-based code works in D.
"Copy and then never use the original again" is conceptually the
same th
On Sunday, February 16, 2020 10:53:36 AM MST Paul Backus via Digitalmars-d-
learn wrote:
> On Sunday, 16 February 2020 at 17:10:24 UTC, Jonathan M Davis
>
> wrote:
> > On Sunday, February 16, 2020 7:29:11 AM MST uranuz via
> >
> >> This is working fine with disabled postblit...
> >> import std;
> >
On Sunday, 16 February 2020 at 17:10:24 UTC, Jonathan M Davis
wrote:
On Sunday, February 16, 2020 7:29:11 AM MST uranuz via
This is working fine with disabled postblit...
import std;
struct SS
{
@disable this(this); // Disabled copy
bool _empty = false;
bool empty() @property {
On Sunday, February 16, 2020 6:52:17 AM MST uranuz via Digitalmars-d-learn
wrote:
> It's very bad. Because there seem that when I use range based
> algorithm I need to take two things into account. The first is
> how algrorithm is implemented. If it creates copies of range
> inside or pass it by r
On Sunday, February 16, 2020 7:29:11 AM MST uranuz via Digitalmars-d-learn
wrote:
> On Sunday, 16 February 2020 at 12:38:51 UTC, Jonathan M Davis
>
> wrote:
> > On Sunday, February 16, 2020 3:41:31 AM MST uranuz via
> >
> > Digitalmars-d-learn wrote:
> >> I have reread presentation:
> >> http://dc
On Sunday, 16 February 2020 at 12:38:51 UTC, Jonathan M Davis
wrote:
On Sunday, February 16, 2020 3:41:31 AM MST uranuz via
Digitalmars-d-learn wrote:
I have reread presentation:
http://dconf.org/2015/talks/davis.pdf
We declare that `pure` input range cannot be `unpoped` and we
can't return to t
In general for value-semantics and ref-semantics the different
code is actually needed. But generic algorithm try to pretend
that the logic is the same. But it's not true. But in wide subset
of trivial algorithm it's true. So it's incorrectly interpolated
that it's true for every case. The very
It's very bad. Because there seem that when I use range based
algorithm I need to take two things into account. The first is
how algrorithm is implemented. If it creates copies of range
inside or pass it by reference. And the second is how the range
is implemented if it has value or reference s
e. So
> logically there is no sence of copying input range at all. So
> every Phobos algorithm that declares that it's is working with
> InputRange must be tested for working with range with disabled
> copy constructor and postblit. And if it is not it means that
> this algroithm
lares that it's is working with
InputRange must be tested for working with range with disabled
copy constructor and postblit. And if it is not it means that
this algroithm actually requires a forward range and there we
missing `save` calls?
Because as it was written in this presentation a ran
Also I see the problemme that someone can think that it creates
an input range, because he doesn't provide `save` method, but
actually it creates forward range unexpectedly, because it is
copyable. And it makes what is actually happening in code more
difficult. Some algrorithm can take ranges b
e` type to initialize from it would be a
regular constructor with parameter.
A copy constructor in struct semantics requires that the source
would be actually `the same` type. But for classes source could
be instance of another class that is inherited from current
class. And we cannot prove statically
On 2/15/20 9:45 AM, Jonathan M Davis wrote:
On Saturday, February 15, 2020 7:34:42 AM MST Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 2/15/20 5:53 AM, uranuz wrote:
I am interested in current circumstances when we have new copy
constructor feature what is the purpose of having range
On Saturday, February 15, 2020 7:34:42 AM MST Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 2/15/20 5:53 AM, uranuz wrote:
> > I am interested in current circumstances when we have new copy
> > constructor feature what is the purpose of having range `save`
> > p
On 2/15/20 5:53 AM, uranuz wrote:
I am interested in current circumstances when we have new copy
constructor feature what is the purpose of having range `save`
primitive? For me they look like doing basicaly the same thing. And when
looking in some source code of `range` module the most common
I am interested in current circumstances when we have new copy
constructor feature what is the purpose of having range `save`
primitive? For me they look like doing basicaly the same thing.
And when looking in some source code of `range` module the most
common thing that `save` does is that it
on of that?
Copy constructors were added (sort of like postblit).
https://dlang.org/spec/struct.html#struct-copy-constructor
Is it temporarily situation?
No.
My question is why the struct may not define both a rvalue ctor and a
copy ctor?
rt of like postblit).
https://dlang.org/spec/struct.html#struct-copy-constructor
Is it temporarily situation?
No.
struct Foo
{
this(ref const(Foo) other) {}
this(const(Foo) other) {}
}
I'm trying to update dmd version and starting from 2.086 my code doesn't
compile due to the error above. What is the reason of that? Is it
temporarily situation?
94 matches
Mail list logo
