On Monday, October 8, 2018 4:27:47 AM MDT RazvanN via Digitalmars-d-announce
wrote:
> On Monday, 8 October 2018 at 10:26:17 UTC, Nicholas Wilson wrote:
> > On Monday, 8 October 2018 at 10:14:51 UTC, RazvanN wrote:
> >> On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote:
> >>> Hi all,
> >>>
On Monday, 8 October 2018 at 10:27:47 UTC, RazvanN wrote:
Both the DIP and the implementation still lack a -dip10xx
switch.
After discussing with Walter and Andrei we came to the
conclusion that a flag is not necessary in this case.
Please elaborate on the reasoning.
Immediately after the
On Monday, 8 October 2018 at 10:14:51 UTC, RazvanN wrote:
On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote:
Hi all,
I just pushed another version of the DIP in which the major
modifications among otthers are removing implicit and use copy
constructor calls in all situations where a
On Monday, 8 October 2018 at 10:26:17 UTC, Nicholas Wilson wrote:
On Monday, 8 October 2018 at 10:14:51 UTC, RazvanN wrote:
On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote:
Hi all,
I just pushed another version of the DIP in which the major
modifications among otthers are removing
On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote:
Hi all,
I just pushed another version of the DIP in which the major
modifications among otthers are removing implicit and use copy
constructor calls in all situations where a copy is made. For
more details, please visit [1] and if
Hi all,
I just pushed another version of the DIP in which the major
modifications among otthers are removing implicit and use copy
constructor calls in all situations where a copy is made. For
more details, please visit [1] and if you have the time, please
offer some feedback,
Thank you,
On Tuesday, 25 September 2018 at 12:33:30 UTC, RazvanN wrote:
After discussing with Walter and Andrei we have decided that we
are going to drop @implicit for now as it may cause bugs (as
Jonathan has highlighted) and consider constructors that have
the form this(ref $q1 S rhs) $q2 as copy
On Tuesday, September 25, 2018 6:33:30 AM MDT RazvanN via Digitalmars-d-
announce wrote:
> After discussing with Walter and Andrei we have decided that we
> are going to drop @implicit for now as it may cause bugs (as
> Jonathan has highlighted) and consider constructors that have the
> form
On Monday, September 24, 2018 9:33:19 PM MDT Manu via Digitalmars-d-announce
wrote:
> On Mon, 24 Sep 2018 at 16:22, Jonathan M Davis via
>
> Digitalmars-d-announce wrote:
> > On Monday, September 24, 2018 3:20:28 PM MDT Manu via
> > Digitalmars-d-announce>
> > wrote:
> > > copy-ctor is good,
On Mon, 24 Sep 2018 at 16:22, Jonathan M Davis via
Digitalmars-d-announce wrote:
>
> On Monday, September 24, 2018 3:20:28 PM MDT Manu via Digitalmars-d-announce
> wrote:
> > copy-ctor is good, @implicit is also good... we want both. Even though
> > copy-ctor is not strictly dependent on
On Monday, September 24, 2018 7:59:36 PM MDT Nicholas Wilson via
Digitalmars-d-announce wrote:
> On Monday, 24 September 2018 at 23:22:13 UTC, Jonathan M Davis
>
> wrote:
> > @implicit on copy constructors is outright bad. It would just
> > be a source of bugs. Every time that someone forgets to
On Monday, 24 September 2018 at 23:22:13 UTC, Jonathan M Davis
wrote:
@implicit on copy constructors is outright bad. It would just
be a source of bugs. Every time that someone forgets to use it
(which plenty of programmers will forget, just like they forget
to use @safe, pure, nothrow, etc.),
On Monday, September 24, 2018 3:20:28 PM MDT Manu via Digitalmars-d-announce
wrote:
> copy-ctor is good, @implicit is also good... we want both. Even though
> copy-ctor is not strictly dependent on @implicit, allowing it will
> satisfy that there's not a breaking change, it it will also
>
On Monday, September 24, 2018 10:44:01 AM MDT Meta via Digitalmars-d-
announce wrote:
> On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis
>
> wrote:
> > @implicit is just there because of the fear of breaking a
> > theoretical piece of code that's going to be extremely rare if
> > it
On Mon, 24 Sep 2018 at 12:40, 12345swordy via Digitalmars-d-announce
wrote:
>
> On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
> > On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via
> > Digitalmars-d-announce
> > wrote:
> >>
> >> On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas
On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via
Digitalmars-d-announce
wrote:
On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson
wrote:
> It appears that @implicit has been removed from the
> implementation [1], but not
On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via
Digitalmars-d-announce wrote:
>
> On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson
> wrote:
> > It appears that @implicit has been removed from the
> > implementation [1], but not yet from the DIP.
> >
> >
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis
wrote:
@implicit is just there because of the fear of breaking a
theoretical piece of code that's going to be extremely rare if
it exists at all and in most cases would continue to work just
fine even if it did exist.
- Jonathan
On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson
wrote:
It appears that @implicit has been removed from the
implementation [1], but not yet from the DIP.
https://github.com/dlang/dmd/commit/cdd8100
Good, It's not needed.
On Saturday, September 22, 2018 8:40:15 PM MDT Nicholas Wilson via
Digitalmars-d-announce wrote:
> On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe
> >
> > via Digitalmars-d-announce wrote:
> >> [...]
> >
>
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis
wrote:
On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe
via Digitalmars-d-announce wrote:
[...]
Yeah, the problem has to do with how much you have to mark up
your code. Whether you have @foo @bar @baz or foo bar baz
On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe via
Digitalmars-d-announce wrote:
> On Saturday, 22 September 2018 at 17:43:57 UTC, 12345swordy wrote:
> > If that where the case, then why not make it an actual keyword?
> > A frequent complaint regarding D is that there are too many
>
On Saturday, 22 September 2018 at 17:43:57 UTC, 12345swordy wrote:
If that where the case, then why not make it an actual keyword?
A frequent complaint regarding D is that there are too many
attributes, this will undoubtedly adding more to it.
When I (and surely others like me) complain that
On Monday, 17 September 2018 at 23:07:22 UTC, Manu wrote:
On Mon, 17 Sep 2018 at 13:55, 12345swordy via
Digitalmars-d-announce
wrote:
On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> Hello everyone,
>
> I have finished writing the last details of the copy
> constructor DIP[1]
On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis
wrote:
On Monday, September 17, 2018 8:27:16 AM MDT Meta via
Digitalmars-d-announce wrote:
[...]
Honestly, I don't think that using a pragma instead of an
attribute fixes much, and it goes against the idea of what
pragmas are
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis
wrote:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via
Digitalmars-d- announce wrote:
This will break compilation of current code that has an
explicit copy constructor, and the fix is simply to add the
attribute
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis
wrote:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via
Digitalmars-d- announce wrote:
This will break compilation of current code that has an
explicit copy constructor, and the fix is simply to add the
attribute
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis
wrote:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via
Digitalmars-d- announce wrote:
This will break compilation of current code that has an
explicit copy constructor, and the fix is simply to add the
attribute
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via Digitalmars-d-
announce wrote:
> This will break compilation of current code that has an explicit
> copy constructor, and the fix is simply to add the attribute
> @implicit.
In that case, why not just use a transitional compiler switch? Why
On Monday, 17 September 2018 at 23:32:39 UTC, Jonathan M Davis
wrote:
On Monday, September 17, 2018 5:07:22 PM MDT Manu via
Digitalmars-d-announce wrote:
[...]
Except that @implicit could be introduced for other
constructors without having it on copy constructors, and the
fact that copy
On Monday, 17 September 2018 at 23:14:28 UTC, tide wrote:
From what I've read, the copy constructor can be used with
different types:
struct B
{
}
struct A
{
@implicit this(ref B b)
{
}
}
B foo();
A a;
a = foo(); // ok because of @implicit
a = A(foo()); // ok without @implicit
On Monday, September 17, 2018 5:07:22 PM MDT Manu via Digitalmars-d-announce
wrote:
> On Mon, 17 Sep 2018 at 13:55, 12345swordy via Digitalmars-d-announce
>
> wrote:
> > On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> > > Hello everyone,
> > >
> > > I have finished writing the
On Monday, September 17, 2018 5:14:28 PM MDT tide via Digitalmars-d-announce
wrote:
> On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis
>
> wrote:
> > Basically, @implicit is being proposed out of fear that
> > someone, somewhere wrote a constructor that had what would be a
> > copy
On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis
wrote:
Basically, @implicit is being proposed out of fear that
someone, somewhere wrote a constructor that had what would be a
copy constructor if D had them instead of postblit constructors
and that that code would break with the
On Mon, 17 Sep 2018 at 13:55, 12345swordy via Digitalmars-d-announce
wrote:
>
> On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> > Hello everyone,
> >
> > I have finished writing the last details of the copy
> > constructor DIP[1] and also I have published the first
> >
On Monday, September 17, 2018 2:53:42 PM MDT 12345swordy via Digitalmars-d-
announce wrote:
> On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> > Hello everyone,
> >
> > I have finished writing the last details of the copy
> > constructor DIP[1] and also I have published the first
>
On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
Hello everyone,
I have finished writing the last details of the copy
constructor DIP[1] and also I have published the first
implementation [2]. As I wrongfully made a PR for the DIP queue
in the early stages of the development of
On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis
wrote:
We're talking about introducing an attribute that should be
unnecessary, which will be annoying to use, and which will be
error-prone given the bugs that you'll get if you forget to
mark your copy constructor with it. And
On Monday, September 17, 2018 8:27:16 AM MDT Meta via Digitalmars-d-announce
wrote:
> On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> > Hello everyone,
> >
> > I have finished writing the last details of the copy
> > constructor DIP[1] and also I have published the first
> >
On Monday, September 17, 2018 7:30:24 AM MDT rmc via Digitalmars-d-announce
wrote:
> On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis
>
> wrote:
> > [snip]
> > Personally, I'd rather that we just risk the code breakage
> > caused by not having an attribute for copy constructors
On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
Hello everyone,
I have finished writing the last details of the copy
constructor DIP[1] and also I have published the first
implementation [2]. As I wrongfully made a PR for the DIP queue
in the early stages of the development of
On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis
wrote:
[snip]
Personally, I'd rather that we just risk the code breakage
caused by not having an attribute for copy constructors than
use either @implicit or @copy, since it really only risks
breaking code using constructors
On Wednesday, September 12, 2018 5:55:05 PM MDT Nicholas Wilson via
Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 23:36:11 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, September 12, 2018 5:17:44 PM MDT Nicholas Wilson
> >
> > via Digitalmars-d-announce wrote:
> >> it
On Wednesday, 12 September 2018 at 23:55:05 UTC, Nicholas Wilson
wrote:
The bog-standard way of dealing with avoidable breakage with
DIPs is a -dip-10xx flag. In this case, if set, would prefer to
call copy constructors over blit + postblit.
Also adding @implicit is a backwards incompatible
On Wednesday, 12 September 2018 at 23:36:11 UTC, Jonathan M Davis
wrote:
On Wednesday, September 12, 2018 5:17:44 PM MDT Nicholas Wilson
via Digitalmars-d-announce wrote:
it seems that even if we were to want to have @implicit as an
opposite of C++'s explicit it would _always_ be present on
On Wednesday, September 12, 2018 4:11:20 PM MDT Manu via Digitalmars-d-
announce wrote:
> On Wed, 12 Sep 2018 at 04:40, Dejan Lekic via Digitalmars-d-announce
>
> wrote:
> > On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
> >
> > wrote:
> > > Here is a question (that I don't think
On Wednesday, September 12, 2018 5:17:44 PM MDT Nicholas Wilson via
Digitalmars-d-announce wrote:
> it seems that even if we were to want to have @implicit as an
> opposite of C++'s explicit it would _always_ be present on
> copy-constructors which means that @implicit for copy
> constructors
On Wednesday, 12 September 2018 at 22:11:20 UTC, Manu wrote:
On Wed, 12 Sep 2018 at 04:40, Dejan Lekic via
Digitalmars-d-announce
wrote:
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki
cattermole wrote:
>
> Here is a question (that I don't think has been asked) why
> not
> @copy?
>
On Wed, 12 Sep 2018 at 04:40, Dejan Lekic via Digitalmars-d-announce
wrote:
>
> On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
> wrote:
> >
> > Here is a question (that I don't think has been asked) why not
> > @copy?
> >
> > @copy this(ref Foo other) { }
> >
> > It can be read
On Wednesday, 12 September 2018 at 19:39:21 UTC, Jonathan M Davis
wrote:
However, Andrei does not believe that the risk is worth it and
insists that we need a way to differentiate between the new
copy constructors and any existing constructors that happen to
look like them. So, there won't be
On Tue, Sep 11, 2018 at 03:08:33PM +, RazvanN via Digitalmars-d-announce
wrote:
> I have finished writing the last details of the copy constructor
> DIP[1] and also I have published the first implementation [2].
[...]
Here are some comments:
- The DIP should address what @implicit means
On Wednesday, September 12, 2018 1:18:11 PM MDT Gary Willoughby via
Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis
>
> wrote:
> > Ultimately, I expect that if we add any attribute for this,
> > people coming to D are going to think that it's
On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis
wrote:
Ultimately, I expect that if we add any attribute for this,
people coming to D are going to think that it's downright
weird, but if we're going to have one, if we go with @implicit,
we're future-proofing things a bit, and
On Wednesday, September 12, 2018 10:04:57 AM MDT Elie Morisse via
Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic
>
> wrote:
> > On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
> >
> > wrote:
> >> Here is a question (that I don't think
On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic
wrote:
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
wrote:
Here is a question (that I don't think has been asked) why not
@copy?
@copy this(ref Foo other) { }
It can be read as copy constructor, which would be
On Tuesday, 11 September 2018 at 23:56:56 UTC, Walter Bright
wrote:
On 9/11/2018 8:08 AM, RazvanN wrote:
[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688
Thank you, RazvanN!
I very much agree!
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
wrote:
Here is a question (that I don't think has been asked) why not
@copy?
@copy this(ref Foo other) { }
It can be read as copy constructor, which would be excellent
for helping people learn what it is doing (spec lookup).
On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
Hello everyone,
I have finished writing the last details of the copy
constructor DIP[1] and also I have published the first
implementation [2]. As I wrongfully made a PR for the DIP queue
in the early stages of the development of
On 9/11/2018 8:08 AM, RazvanN wrote:
[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688
Thank you, RazvanN!
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
wrote:
Here is a question (that I don't think has been asked) why not
@copy?
It's not wrong to call this an implicit constructor since it's
called implicitly. It also means that, if we get implicit
constructors in general, we
On 12/09/2018 3:08 AM, RazvanN wrote:
Hello everyone,
I have finished writing the last details of the copy constructor DIP[1]
and also I have published the first implementation [2]. As I wrongfully
made a PR for the DIP queue in the early stages of the development of
the DIP, I want to
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
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!
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
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
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
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
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
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
> >>
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
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
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
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
{
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
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,
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
[...]
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
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
1 - 100 of 177 matches
Mail list logo
