This should probably have been posted here. -- Andrei
Forwarded Message
Subject: Copy Constructor DIP and implementation
Date: Tue, 11 Sep 2018 15:08:33 +
From: RazvanN
Organization: Digital Mars
Newsgroups: digitalmars.D.announce
Hello everyone,
I have finished writing
On Tue, 17 Jul 2018 at 10:20, aliak via Digitalmars-d
wrote:
>
> On Friday, 13 July 2018 at 12:31:41 UTC, 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
On Friday, 13 July 2018 at 12:31:41 UTC, 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
On Tuesday, 17 July 2018 at 14:41:06 UTC, ag0aep6g wrote:
On 07/17/2018 03:03 PM, aliak00 wrote:
[...]
In a UDA `@implicit`, `implicit` is just a normal symbol. So
the normal lookup rules apply. In particular, you can shadow an
imported `implicit` with a local one:
[...]
Ah, gotcha! Than
On 07/17/2018 03:03 PM, aliak00 wrote:
Can you explain a bit more here? How does having implicit as a compiler
recognized UDA avoid breaking changes as opposed to it being implemented
like @nogc/@safe (how are those implemented differently anyway?)
In a UDA `@implicit`, `implicit` is just a no
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu
wrote:
I think it's better to choose a more general attribute name
with reduced initial applicability. Then application of said
attribute can be extended to other functions with ease. In
contrast, an obscure attribute name is sure t
On Saturday, 14 July 2018 at 00:57:14 UTC, Andrei Alexandrescu
wrote:
[...]
chucklesomely profligate and ridiculously baroque.
Andrei
Hahaha this sentence... amazing! :D
I was going to propose auto this(ref A other) {} but nevermind :p
Cheers,
- Ali
On Tuesday, 17 July 2018 at 04:04:33 UTC, Manu wrote:
On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu
wrote:
> On 7/14/18 5:03 AM, Luís Marques wrote:
>> If there is "no other mean
On Tuesday, 17 July 2018 at 07:27:32 UTC, Jacob Carlborg wrote:
On Tuesday, 17 July 2018 at 00:04:12 UTC, Andrei Alexandrescu
wrote:
Then "negative" :o). In brief @implicit follows the same
implementation as @safe and @nogc/
Why? This is a breaking change. Why not go with an approach
that d
On 7/17/18 12:04 AM, Manu wrote:
But that's the point, and the key advantage of the name ;)
[:nod:]
On 7/16/18 8:57 PM, docandrew wrote:
I think in this case, a more obscure name like @copyctor is more
descriptive.
On the contrary, it is redundant and uninformative. It applies to
exactly a constructor that copies, so it adds no information.
"@implicit" describes precisely what the attribute
On Tuesday, 17 July 2018 at 00:04:12 UTC, Andrei Alexandrescu
wrote:
Then "negative" :o). In brief @implicit follows the same
implementation as @safe and @nogc/
Why? This is a breaking change. Why not go with an approach that
does not cause any breaking changes, which is just as easy to do?
On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu
> wrote:
> > On 7/14/18 5:03 AM, Luís Marques wrote:
> >> If there is "no other meaning of @implicit" (other than the
> >> intersection
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu
wrote:
On 7/14/18 5:03 AM, Luís Marques wrote:
If there is "no other meaning of @implicit" (other than the
intersection of those two properties) why don't you just call
it something like @copyctor?
I'm totally cool with giving the
On 7/16/18 3:12 PM, ag0aep6g wrote:
On 07/16/2018 09:06 PM, Andrei Alexandrescu wrote:
On 7/14/18 11:26 AM, Jacob Carlborg wrote:
[...]
That's easily fixed by implementing a compiler recognized UDA. That
would mean that it would only be a copy constructor if "implicit" is
defined in core.attr
On 07/16/2018 09:06 PM, Andrei Alexandrescu wrote:
On 7/14/18 11:26 AM, Jacob Carlborg wrote:
[...]
That's easily fixed by implementing a compiler recognized UDA. That
would mean that it would only be a copy constructor if "implicit" is
defined in core.attribute. This would also avoid any spec
On 7/14/18 11:26 AM, Jacob Carlborg wrote:
On Friday, 13 July 2018 at 01:18:48 UTC, Andrei Alexandrescu wrote:
On 7/12/18 2:30 PM, ag0aep6g wrote:
You're still potentially changing the semantics of existing code.
`@implicit` can be a UDA today:
enum implicit = 0;
struct C
{
@impli
On Friday, 13 July 2018 at 11:02:57 UTC, RazvanN wrote:
[...]
Indeed, but this was the source of the problem also, because
you could
modify immutable fields that way.
[...]
Affirmative. The DIP needs to specify how assignment is
handled if no opAssign is present but a copy ctor is presen
On Friday, 13 July 2018 at 01:18:48 UTC, Andrei Alexandrescu
wrote:
On 7/12/18 2:30 PM, ag0aep6g wrote:
You're still potentially changing the semantics of existing
code. `@implicit` can be a UDA today:
enum implicit = 0;
struct C
{
@implicit this(ref C another) {}
}
Today, th
On 14/07/2018 11:49 PM, Johan Engelen wrote:
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote:
I now deeply regret ever telling Razvan to mention future possible
directions. This DIP must do implicit copy constructors and do it
well, nothing less and nothing more.
Strong
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu
wrote:
I now deeply regret ever telling Razvan to mention future
possible directions. This DIP must do implicit copy
constructors and do it well, nothing less and nothing more.
Strongly agree with this.
In my review on Github I h
On 7/14/18 5:03 AM, Luís Marques wrote:
If there is "no other meaning of @implicit" (other than the intersection
of those two properties) why don't you just call it something like
@copyctor?
I'm totally cool with giving the attribute a more obscure name such as
@copyctor or anything people wa
On Sat., 14 Jul. 2018, 2:00 am rikki cattermole via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On 14/07/2018 1:04 PM, Manu wrote:
> > Determining that requires at least a cursory exploration.
>
> Given how many of us are objecting to the syntax, I'm going to place
> this requirement up
On Saturday, 14 July 2018 at 00:41:37 UTC, Andrei Alexandrescu
wrote:
The specification of @implicit is in the DIP in full: a
constructor that takes by reference a qualified typeof(this)
and has the @implicit attribute will be callable implicitly by
the compiler. There is no other meaning of @i
On 14/07/2018 1:04 PM, Manu wrote:
Determining that requires at least a cursory exploration.
Given how many of us are objecting to the syntax, I'm going to place
this requirement upon a 'yes' answer by me. That an attempt is made for
an alternative syntax discussion. It's a fair request I thi
On Fri, 13 Jul 2018 at 18:00, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 7/13/18 5:49 PM, rikki cattermole wrote:
> > On 14/07/2018 9:28 AM, Manu wrote:
> >> I've already contributed other points to this DIP in the way you
> >> describe.
> >> This one however is very strange, and I'm surp
On Fri, 13 Jul 2018 at 17:45, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 7/13/18 5:28 PM, Manu wrote:
> > As I originally said, my feedback is concrete: specify @implicit, this
> > DIP depends on it.
>
> The specification of @implicit is in the DIP in full: a constructor that
> takes by r
On 7/13/18 5:49 PM, rikki cattermole wrote:
On 14/07/2018 9:28 AM, Manu wrote:
I've already contributed other points to this DIP in the way you
describe.
This one however is very strange, and I'm surprised you can find the
hand-wavy introduction of a new attribute without any sense of where
it'
On 7/13/18 5:28 PM, Manu wrote:
As I originally said, my feedback is concrete: specify @implicit, this
DIP depends on it.
The specification of @implicit is in the DIP in full: a constructor that
takes by reference a qualified typeof(this) and has the @implicit
attribute will be callable impli
On Friday, 13 July 2018 at 21:49:57 UTC, rikki cattermole wrote:
On 14/07/2018 9:28 AM, Manu wrote:
I've already contributed other points to this DIP in the way
you describe.
This one however is very strange, and I'm surprised you can
find the
hand-wavy introduction of a new attribute without a
On 14/07/2018 9:28 AM, Manu wrote:
I've already contributed other points to this DIP in the way you describe.
This one however is very strange, and I'm surprised you can find the
hand-wavy introduction of a new attribute without any sense of where
it's going to be okay. Or maybe, I'm surprised I'
On Fri, 13 Jul 2018 at 07:35, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 7/12/18 11:45 PM, Manu wrote:
> >
> > I can see myself getting behind 2 possibilities, no @implicit, or
> > @implicit done right.
>
> A couple of simple ideas are making the process productive. One is to
> rely on fa
On Friday, 13 July 2018 at 18:54:48 UTC, Manu wrote:
As a marker used in this one case, it's a terrible name, as a
generalised concept, it's perfect.
Exactly.
On Fri, 13 Jul 2018 at 10:35, Atila Neves via Digitalmars-d
wrote:
>
> [...]
>
> Now that I understand the implicit call `@implicit` makes sense
> to me but I'm convinced it'll confuse more people than not. I'll
> see if I can come up with a better name.
You don't find 'implicit' satisfactory as
On Fri, 13 Jul 2018 at 07:40, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> 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 existin
On Fri, 13 Jul 2018 at 04:05, RazvanN via Digitalmars-d
wrote:
>
> > [...]
>
> The problem with this approach is that some copy constructors
> will also be used as assignment operators while others will not,
> but with good error messages it could be handled (error on line
> `f = d` : opAssign not
On Friday, 13 July 2018 at 16:02:51 UTC, Andrei Alexandrescu
wrote:
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.co
On 7/13/18 12:06 PM, xenon325 wrote:
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 us
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 impl
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 @implicit).
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&type=Code
The answer see
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&type=Code
The answer seems to be: not many. Most of the results a
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 somethin
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:
>>
[..]
doe
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. the
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 s
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 explai
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 substanti
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 y
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 Thursday,
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 implement
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,
th
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 i
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
a
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 exis
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 relax
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 wordin
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 *ex
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 c
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 *ex
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 c
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 constru
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 pot
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 discu
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:
>>
>> @this
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 myria
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 propos
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 sus
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 implici
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 accomodate
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 bad
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 r
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;
O
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 a
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 desi
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 the
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 ass
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 lie
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 obvio
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 c
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 opAs
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 t
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)
thi
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 for
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 mayb
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 @impli
1 - 100 of 118 matches
Mail list logo
