From the DIP:
The copy constructor declaration will be recognized by the
parser when the tokens @, implicit, this are encountered
exactly in this order
Regarding "exactly in this order". The code below would be
allowed and define copy c'tor for `A` and usual c'tor for `B` ?
struct
On Friday, 13 July 2018 at 16:02:51 UTC, Andrei Alexandrescu
wrote:
On 7/13/18 11:14 AM, Atila Neves wrote:
[...]
Great. Razvan, can you please add this example with discussion
to the DIP (probably at the end of the Motivation section as an
explanation why we need the addition of
On 7/13/18 11:14 AM, Atila Neves wrote:
On Friday, 13 July 2018 at 14:12:59 UTC, Andrei Alexandrescu wrote:
On 7/13/18 8:31 AM, Atila Neves wrote:
On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote:
[...]
https://github.com/search?q=%22this%5C%28ref%22+language%3AD=Code
The answer seems
On Friday, 13 July 2018 at 14:12:59 UTC, Andrei Alexandrescu
wrote:
On 7/13/18 8:31 AM, Atila Neves wrote:
On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote:
[...]
https://github.com/search?q=%22this%5C%28ref%22+language%3AD=Code
The answer seems to be: not many. Most of the results above
On 7/12/18 11:01 PM, Manu wrote:
What existing code are you changing the semantics of?
It's still not clear to me how accepting `this(ref T)` as a magic
signature that is a copy constructor can break existing code?
Is it the unlikely^^2 case that the function exists somewhere and
doesn't perform
On 7/12/18 11:45 PM, Manu wrote:
On Thu, 12 Jul 2018 at 20:15, Meta via Digitalmars-d
wrote:
On Friday, 13 July 2018 at 02:32:59 UTC, Manu wrote:
Seriously, if I was making this proposal to you, and you were in
my position... there is no way in hell that you'd allow any of
us to slip
On 7/13/18 8:31 AM, Atila Neves wrote:
On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote:
On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/12/18 6:34 PM, Manu wrote:
> On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via >
Digitalmars-d wrote:
>>
[..]
On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote:
On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via
Digitalmars-d wrote:
On 7/12/18 6:34 PM, Manu wrote:
> On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via
> Digitalmars-d wrote:
>>
[..]
doesn't perform copy construction?
1.
In a post-blit world, with no opAssign specified, postblit
will call
for copy construction AND for assignment, thereby assignment
is always
correct.
Once postblit is swapped for a copy-constructor, absence of
opAssign
will result in invalid behaviour on assignment.
Indeed, but this was the
The above code contains a typo. The parameter type of the second
copy constructor is meant to be B not A
On Thursday, 12 July 2018 at 20:29:43 UTC, Manu wrote:
On Wed, 11 Jul 2018 at 23:55, RazvanN via Digitalmars-d
wrote:
> What's wrong with:
> struct S {
> this(ref S copyFrom);
> }
>
> That looks like a perfectly good copy constructor
> declaration ;) I'm just saying, the DIP needs to
On Thu, 12 Jul 2018 at 20:15, Meta via Digitalmars-d
wrote:
>
> On Friday, 13 July 2018 at 02:32:59 UTC, Manu wrote:
> > Seriously, if I was making this proposal to you, and you were
> > in my
> > position... there is no way in hell that you'd allow any of us
> > to slip
> > something so
On Friday, 13 July 2018 at 02:32:59 UTC, Manu wrote:
Seriously, if I was making this proposal to you, and you were
in my
position... there is no way in hell that you'd allow any of us
to slip
something so substantial by like that with the wave of a hand.
This DIP depends on @implicit. How can
On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 7/12/18 6:34 PM, Manu wrote:
> > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
> > wrote:
> >>
> >> On 07/11/2018 11:11 AM, Atila Neves wrote:
> >>> On Wednesday, 11 July 2018 at 07:40:32 UTC,
On Thu., 12 Jul. 2018, 7:10 pm Andrei Alexandrescu via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On 7/12/18 7:15 PM, Manu wrote:
> > On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
> > wrote:
> >>
> >> On 07/12/2018 11:14 AM, Luís Marques wrote:
> >>> On
On 7/12/18 10:05 PM, Manu wrote:
On Thu, 12 Jul 2018 at 18:25, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/12/18 4:29 PM, Manu wrote:
Being able to implement them both independently is*occasionally*
useful, but 95% of the time, destruct + copy-construct is an equally
efficient
On 7/12/18 6:37 PM, Manu wrote:
On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d
wrote:
On 07/12/2018 09:49 AM, Atila Neves wrote:
On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
[...]
If by "come in pairs" you mean that you can define them both, then yes,
On 7/12/18 6:34 PM, Manu wrote:
On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
wrote:
On 07/11/2018 11:11 AM, Atila Neves wrote:
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right there...
so should we
On 7/12/18 7:15 PM, Manu wrote:
On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
wrote:
On 07/12/2018 11:14 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
When designing D libraries than lean towards DSL style, I've
frequently felt
On Thu, 12 Jul 2018 at 18:25, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 7/12/18 4:29 PM, Manu wrote:
> > Being able to implement them both independently is*occasionally*
> > useful, but 95% of the time, destruct + copy-construct is an equally
> > efficient implementation for assignment.
On 7/12/18 4:29 PM, Manu wrote:
Being able to implement them both independently is*occasionally*
useful, but 95% of the time, destruct + copy-construct is an equally
efficient implementation for assignment. I'd suggest that this
destruct+copy-construct pattern is a perfectly good substitute for
On 7/12/18 2:30 PM, ag0aep6g wrote:
On 07/12/2018 03:40 PM, Andrei Alexandrescu wrote:
On 07/10/2018 04:58 PM, Manu wrote:
[...]
1. Explain the need and reasoning behind `@implicit`.
Razvan: I think it would help to explain that the attribute is
necessary to avoid changing semantics of
On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/12/2018 11:14 AM, Luís Marques wrote:
> > On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
> >> When designing D libraries than lean towards DSL style, I've
> >> frequently felt impaired by the lack
On Thu, 12 Jul 2018 at 08:30, Luís Marques via Digitalmars-d
wrote:
>
> On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
> > More details. The DIP says:
> >
> > "The structName type needs to be identical to typeof(this); an
> > error is issued otherwise. This requirement may be
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
wrote:
>
> Hi everyone!
>
> I managed to put together a first draft of the DIP for adding the
> copy constructor to the language [1]. If anyone is interested,
> please take a look. Suggestions and comments about technical
> aspects and
On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/11/2018 11:11 AM, Atila Neves wrote:
> > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
> >>> But there's a super explicit `@implicit` thing written right there...
> >>> so should we expect that an
On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/12/2018 09:49 AM, Atila Neves wrote:
> > On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
> >
> >> [...]
> >
> >> If by "come in pairs" you mean that you can define them both, then yes,
> >> that is the
On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/11/2018 11:11 AM, Atila Neves wrote:
> > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
> >>> But there's a super explicit `@implicit` thing written right there...
> >>> so should we expect that an
On Thu, 12 Jul 2018 at 06:45, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/10/2018 06:50 PM, Manu wrote:
> > On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d
> > wrote:
> >>
> >> On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
> >>> 2. It looks like
On Wed, 11 Jul 2018 at 23:55, RazvanN via Digitalmars-d
wrote:
>
> > What's wrong with:
> > struct S {
> > this(ref S copyFrom);
> > }
> >
> > That looks like a perfectly good copy constructor declaration
> > ;) I'm just saying, the DIP needs to explain this.
>
> That is actually a valid
On 07/12/2018 03:40 PM, Andrei Alexandrescu wrote:
On 07/10/2018 04:58 PM, Manu wrote:
[...]
1. Explain the need and reasoning behind `@implicit`.
Razvan: I think it would help to explain that the attribute is necessary
to avoid changing semantics of existing code. Thanks.
You're still
Am Thu, 12 Jul 2018 17:32:06 + schrieb Johannes Pfau:
> Am Thu, 12 Jul 2018 09:48:37 -0400 schrieb Andrei Alexandrescu:
>
>>> I agree that the current syntax is lacking. This was Andrei's
>>> proposition and I was initially against it, but he said to put it in
>>> the DIP so that we can
Am Thu, 12 Jul 2018 09:48:37 -0400 schrieb Andrei Alexandrescu:
>> I agree that the current syntax is lacking. This was Andrei's
>> proposition and I was initially against it, but he said to put it in
>> the DIP so that we can discuss it as a community. Maybe this syntax is
>> better:
>>
>>
On 7/12/18 11:42 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu wrote:
Again: not the charter of this DIP, so you should ask yourself, not
us, this question.
Look, I understand it can be frustrating to have a concrete design
proposal derailed by a
On Thursday, 12 July 2018 at 15:42:29 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu
wrote:
Again: not the charter of this DIP, so you should ask
yourself, not us, this question.
Look, I understand it can be frustrating to have a concrete
design
On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu
wrote:
Again: not the charter of this DIP, so you should ask yourself,
not us, this question.
Look, I understand it can be frustrating to have a concrete
design proposal derailed by a myriad of speculative questions.
But if we
On Thursday, 12 July 2018 at 15:34:25 UTC, Andrei Alexandrescu
wrote:
The DIP mentions the interaction of @implicit with alias this.
Not the interaction I was asking about, although admittedly it
was speculative.
On 07/12/2018 11:14 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
When designing D libraries than lean towards DSL style, I've
frequently felt impaired by the lack of implicit conversions in D. In
my experience, it's not that all types need to be
On 07/12/2018 11:29 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:25:10 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
BTW: Multiple alias this is still planned for inclusion in D, right?
If so, what would be the (pratical?) difference between
On 07/12/2018 11:25 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
More details. The DIP says:
"The structName type needs to be identical to typeof(this); an error
is issued otherwise. This requirement may be relaxed in the future in
order to
On 07/12/2018 11:22 AM, Timon Gehr wrote:
On 12.07.2018 15:29, Andrei Alexandrescu wrote:
On 07/11/2018 05:55 AM, Nick Treleaven wrote:
...
Removing `static` works. Otherwise I tried changing `ref` to `alias`:
Error: variable src cannot be read at compile time
But this shorter code seems to
On 07/12/2018 10:54 AM, Jonathan M Davis wrote:
On Thursday, 12 July 2018 07:45:30 MDT Andrei Alexandrescu via Digitalmars-d
wrote:
I also very much dislike the syntax - it makes no sense to me at all. I
commented on the PR itself asking why it differs so much from C++ -
specifically, what's
On 12.07.2018 17:22, Timon Gehr wrote:
alias field0 = s.tupleof[0];
t.tupleof[0] = field0;
alias field1 = s.tupleof[1];
t.tupleof[1] = field1;
alias field2 = s.tupleof[2];
t.tupleof[2] = field2;
Error: alias `a` cannot alias an expression `tuple(s.a, s.b, s.c)[0]`
Error: alias `b` cannot alias
On Thursday, 12 July 2018 at 15:25:10 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
BTW: Multiple alias this is still planned for inclusion in D,
right? If so, what would be the (pratical?) difference between
having copy ctors with such a relaxed type
On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
More details. The DIP says:
"The structName type needs to be identical to typeof(this); an
error is issued otherwise. This requirement may be relaxed in
the future in order to accomodate copying from objects of a
different type"
On 12.07.2018 15:29, Andrei Alexandrescu wrote:
On 07/11/2018 05:55 AM, Nick Treleaven wrote:
...
Removing `static` works. Otherwise I tried changing `ref` to `alias`:
Error: variable src cannot be read at compile time
But this shorter code seems to work fine:
this.tupleof = src.tupleof;
On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
When designing D libraries than lean towards DSL style, I've
frequently felt impaired by the lack of implicit conversions in
D. In my experience, it's not that all types need to be
implicitly convertible to other types. Just being
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
I managed to put together a first draft of the DIP for adding
the copy constructor to the language [1]. If anyone is
interested, please take a look. Suggestions and comments about
technical aspects and wording are all welcome.
When
On Thursday, 12 July 2018 07:45:30 MDT Andrei Alexandrescu via Digitalmars-d
wrote:
> > I also very much dislike the syntax - it makes no sense to me at all. I
> > commented on the PR itself asking why it differs so much from C++ -
> > specifically, what's bad about the C++ way of doing things
On 07/12/2018 09:49 AM, Atila Neves wrote:
On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
[...]
If by "come in pairs" you mean that you can define them both, then yes,
that is the case. Will add a paragraph in the DIP to specify this.
You mentioned that it's terrible that the
On 07/11/2018 12:19 PM, vit wrote:
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right there...
so should we expect that an *explicit* call to the copy constructor
is not allowed? Or maybe it is allowed and `@implicit` is a
On 07/11/2018 05:28 PM, Manu wrote:
What's wrong with:
struct S {
this(ref S copyFrom);
}
That looks like a perfectly good copy constructor declaration ;)
I'm just saying, the DIP needs to explain this.
Thanks, worth a paragraph discussing silent semantics change.
Right. This is all
On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
[...]
If by "come in pairs" you mean that you can define them both,
then yes,
that is the case. Will add a paragraph in the DIP to specify
this.
You mentioned that it's terrible that the assignment operator
and the copy constructor
On 07/12/2018 02:54 AM, RazvanN wrote:
What's wrong with:
struct S {
this(ref S copyFrom);
}
That looks like a perfectly good copy constructor declaration ;) I'm
just saying, the DIP needs to explain this.
That is actually a valid constructor, according to today's compiler. There
might be
On 07/11/2018 11:11 AM, Atila Neves wrote:
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right there...
so should we expect that an *explicit* call to the copy constructor
is not allowed? Or maybe it is allowed and `@implicit`
On 07/10/2018 06:50 PM, Manu wrote:
On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d
wrote:
On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
2. It looks like copy constructors are used to perform assignments
(and not constructions)... but, there is also
On 07/10/2018 04:58 PM, Manu wrote:
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
wrote:
Hi everyone!
I managed to put together a first draft of the DIP for adding the
copy constructor to the language [1]. If anyone is interested,
please take a look. Suggestions and comments about
On 07/11/2018 05:55 AM, Nick Treleaven wrote:
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
[1] https://github.com/dlang/DIPs/pull/129
Thanks for making the DIP. I can't get this code to compile (my struct
has an `int i` field):
static foreach (i, ref field; src.tupleof)
That's my point; so this is a compile error then:
S b = S(a); // <- explicit construction of copy? ie, explicit
call to
stated `@implicit` function
Consider this code:
import std.stdio : writeln;
struct S
{
this(this)
{
writeln("postblit");
}
int a;
this(int a)
What's wrong with:
struct S {
this(ref S copyFrom);
}
That looks like a perfectly good copy constructor declaration
;) I'm just saying, the DIP needs to explain this.
That is actually a valid constructor, according to today's
compiler. There
might be code out there that uses this syntax
On Wed, 11 Jul 2018 at 09:20, vit via Digitalmars-d
wrote:
>
> On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
> >> But there's a super explicit `@implicit` thing written right
> >> there... so should we expect that an *explicit* call to the
> >> copy constructor is not allowed? Or
On Wed, 11 Jul 2018 at 00:45, RazvanN via Digitalmars-d
wrote:
>
> > But there's a super explicit `@implicit` thing written right
> > there... so should we expect that an *explicit* call to the
> > copy constructor is not allowed? Or maybe it is allowed and
> > `@implicit` is a lie?
>
> The
On Wed, 11 Jul 2018 at 00:40, RazvanN via Digitalmars-d
wrote:
>
> On Tuesday, 10 July 2018 at 20:58:09 UTC, Manu wrote:
> > On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
> > wrote:
> >>
> >> Hi everyone!
> >>
> >> I managed to put together a first draft of the DIP for adding
> >> the
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right
there... so should we expect that an *explicit* call to the
copy constructor is not allowed? Or maybe it is allowed and
`@implicit` is a lie?
The @implicit is there to
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right
there... so should we expect that an *explicit* call to the
copy constructor is not allowed? Or maybe it is allowed and
`@implicit` is a lie?
The @implicit is there to
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
[1] https://github.com/dlang/DIPs/pull/129
Thanks for making the DIP. I can't get this code to compile (my
struct has an `int i` field):
static foreach (i, ref field; src.tupleof)
this.tupleof[i] = field;
Error: constant value
But there's a super explicit `@implicit` thing written right
there... so should we expect that an *explicit* call to the
copy constructor is not allowed? Or maybe it is allowed and
`@implicit` is a lie?
The @implicit is there to point out that you cannot call that
method
explicitly; it gets
On Tuesday, 10 July 2018 at 20:58:09 UTC, Manu wrote:
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
wrote:
Hi everyone!
I managed to put together a first draft of the DIP for adding
the copy constructor to the language [1]. If anyone is
interested, please take a look. Suggestions
On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
> > 2. It looks like copy constructors are used to perform assignments
> > (and not constructions)... but, there is also opAssign. What gives?
> >
On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
> 2. It looks like copy constructors are used to perform assignments
> (and not constructions)... but, there is also opAssign. What gives?
> Eg:
> S b = a; // <- copy construction? looks like an assignment.
> And
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
wrote:
>
> Hi everyone!
>
> I managed to put together a first draft of the DIP for adding the
> copy constructor to the language [1]. If anyone is interested,
> please take a look. Suggestions and comments about technical
> aspects and
On Tuesday, 10 July 2018 at 13:38:33 UTC, Jonathan M Davis wrote:
He thought that it was critical that the invariant be valid
when opAssign was called - and there are cases where that's
arguably true - but since it doesn't work once you try to do
fancier stuff like emplace, I'm of the opinion
On Tuesday, 10 July 2018 at 14:28:09 UTC, FeepingCreature wrote:
On Tuesday, 10 July 2018 at 13:38:33 UTC, Jonathan M Davis
wrote:
[...]
Using types with an invalid T.init feels like playing musical
chairs with a crash. You can shuffle things around, and make
some parts work, but *something*
On 07/10/2018 06:52 AM, Guillaume Piolat wrote:
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
Hi everyone!
I managed to put together a first draft of the DIP for adding the copy
constructor to the language [1]. If anyone is interested, please take
a look. Suggestions and comments
On Tuesday, 10 July 2018 06:34:34 MDT Guillaume Piolat via Digitalmars-d
wrote:
> On Tuesday, 10 July 2018 at 11:58:53 UTC, Jonathan M Davis wrote:
> >> Does it allow to remove the "T.init must always be valid for
> >> structs" rule?
> >
> > Why would it? init is the state of the object before
On Tuesday, 10 July 2018 at 11:58:53 UTC, Jonathan M Davis wrote:
Does it allow to remove the "T.init must always be valid for
structs" rule?
Why would it? init is the state of the object before any
constructor runs, and quite a few things rely on it. The fact
that we've allowed default
I'm not keen on the added attribute.
Something along the lines of:
this(this; ref Foo foo) {}
might look a little better no?
And now no super special attribute to worry about parsing.
On Tuesday, 10 July 2018 04:52:18 MDT Guillaume Piolat via Digitalmars-d
wrote:
> On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
> > Hi everyone!
> >
> > I managed to put together a first draft of the DIP for adding
> > the copy constructor to the language [1]. If anyone is
> >
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
Hi everyone!
I managed to put together a first draft of the DIP for adding
the copy constructor to the language [1]. If anyone is
interested, please take a look. Suggestions and comments about
technical aspects and wording are all
Hi everyone!
I managed to put together a first draft of the DIP for adding the
copy constructor to the language [1]. If anyone is interested,
please take a look. Suggestions and comments about technical
aspects and wording are all welcome.
Thanks,
RazvanN
[1]
101 - 180 of 180 matches
Mail list logo
