Re: Copy Constructor DIP and implementation
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 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 should itself be implicit. > > > > Oh, yes. The whole reason it's there is the fear that not > > requiring it would break code that currently declares a > > constructor that would be a copy constructor if we didn't > > require @implicit. So, if the DIP is accepted, you _could_ > > declare a constructor that should be a copy constructor but > > isn't, because it wasn't marked with @implicit (just like you > > can right now). If code breakage were not a concern, then > > there's pretty much no way that @implicit would be part of the > > DIP. Personally, I don't think that the risk of breakage is > > high enough for it to be worth requiring an attribute for what > > should be the normal behavior (especially when such a > > constructor almost certainly was intended to act like a copy > > constructor, albeit an explicit one), but Andrei doesn't agree. > > 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 change to a > codebase that wants to use it as it will cause it to fail on > older compilers. Even if one does : > > static if (__VERSION__ < 2085) // or whenever it gets implemented > enum implicit; > all over the place, I don't disagree, but it's not my decision. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 change to a codebase that wants to use it as it will cause it to fail on older compilers. Even if one does : static if (__VERSION__ < 2085) // or whenever it gets implemented enum implicit; all over the place, It is illegal to declare a copy constructor for a struct that has a postblit defined and vice versa: Hmm, I suppose one could static if (__VERSION__ < 2085) // use a postblit else // use a copy ctor.
Re: Copy Constructor DIP and implementation
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 copy-constructors which means that @implicit for copy constructors should itself be implicit. Oh, yes. The whole reason it's there is the fear that not requiring it would break code that currently declares a constructor that would be a copy constructor if we didn't require @implicit. So, if the DIP is accepted, you _could_ declare a constructor that should be a copy constructor but isn't, because it wasn't marked with @implicit (just like you can right now). If code breakage were not a concern, then there's pretty much no way that @implicit would be part of the DIP. Personally, I don't think that the risk of breakage is high enough for it to be worth requiring an attribute for what should be the normal behavior (especially when such a constructor almost certainly was intended to act like a copy constructor, albeit an explicit one), but Andrei doesn't agree. 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 change to a codebase that wants to use it as it will cause it to fail on older compilers. Even if one does : static if (__VERSION__ < 2085) // or whenever it gets implemented enum implicit; all over the place, It is illegal to declare a copy constructor for a struct that has a postblit defined and vice versa:
Re: Copy Constructor DIP and implementation
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 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).
> > >
> > > Also can we really not come up with an alternative bit of code
> > > than the tupleof to copying wholesale? E.g. super(other);
> >
> > I could not agree more. @implicit can mean many things, while
> > @copy is much more specific... For what is worth I vote for @copy
> > ! :)
>
> @implicit may be attributed to any constructor allowing it to be
> invoked implicitly. It's the inverse of C++'s `explicit` keyword.
> As such, @implicit is overwhelmingly useful in its own right.
>
> This will address my single biggest usability complaint of D as
> compared to C++. @implicit is super awesome, and we must embrace it.
Except that this DIP doesn't do anything of the sort. It specifically only
affects copy constructors. Yes, in theory, we could later extend @implicit
to do something like what you describe, but there are not currently any
plans to do so. So, @implicit makes more sense than @copy in the sense that
it's more likely to be forward-compatible (or at least, @implicit could be
reused in a sensible manner, whereas @copy couldn't be; so, if we used
@copy, we might also have to introduce @implicit later anyway), but either
way, saying that @implicit has anything to do with adding implicit
construction to D like C++ has is currently false. In fact, the DIP
specifically makes it an error to use @implicit on anything other than a
copy constructor.
- Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 should itself be implicit. Oh, yes. The whole reason it's there is the fear that not requiring it would break code that currently declares a constructor that would be a copy constructor if we didn't require @implicit. So, if the DIP is accepted, you _could_ declare a constructor that should be a copy constructor but isn't, because it wasn't marked with @implicit (just like you can right now). If code breakage were not a concern, then there's pretty much no way that @implicit would be part of the DIP. Personally, I don't think that the risk of breakage is high enough for it to be worth requiring an attribute for what should be the normal behavior (especially when such a constructor almost certainly was intended to act like a copy constructor, albeit an explicit one), but Andrei doesn't agree. > If at some point in the future we decide that we do want to add > @implicit construction, then we can make the copy constructor > always @implicit. Until that point I see no need for this, > because it is replacing postblit which is always called > implicitly. Except that the whole reason that @implicit is being added is to avoid the risk of breaking code, and that problem really isn't going to go away. So, it's hard to see how we would ever be able to remove it. Certainly, if we were willing to take the risks associated with it, there wouldn't be any reason to introduce @implicit in the first place (at least not for copy constructors). If it were my decision, I wouldn't introduce @implicit and would risk the code breakage (which I would expect to be pretty much non-existent much as it theoretically could happen), but it's not my decision. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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?
>
> @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).
>
> Also can we really not come up with an alternative bit of
> code than the tupleof to copying wholesale? E.g.
> super(other);
I could not agree more. @implicit can mean many things, while
@copy is much more specific... For what is worth I vote for
@copy ! :)
@implicit may be attributed to any constructor allowing it to
be invoked implicitly. It's the inverse of C++'s `explicit`
keyword. As such, @implicit is overwhelmingly useful in its own
right.
This will address my single biggest usability complaint of D as
compared to C++. @implicit is super awesome, and we must
embrace it.
https://stackoverflow.com/a/11480555/1112970
I have no idea why you would want to declare a copy-constructor
as explicit
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 should itself be implicit.
From what I understand of explicit in C++, if we were to have
@implicit construction it would be used for things like
struct Foo
{
@implicit this(int) {}
}
void useFoo(Foo f) { ... }
void main()
{
useFoo(0); // Fine, implicitly construct auto tmp = Foo(0);
useFoo(tmp);
}
If at some point in the future we decide that we do want to add
@implicit construction, then we can make the copy constructor
always @implicit. Until that point I see no need for this,
because it is replacing postblit which is always called
implicitly.
@\all please remember to leave feedback on the actual draft
review on the DIP PR.
Re: Copy Constructor DIP and implementation
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 as copy constructor, which would be excellent
> > for helping people learn what it is doing (spec lookup).
> >
> > Also can we really not come up with an alternative bit of code
> > than the tupleof to copying wholesale? E.g. super(other);
>
> I could not agree more. @implicit can mean many things, while
> @copy is much more specific... For what is worth I vote for @copy
> ! :)
@implicit may be attributed to any constructor allowing it to be
invoked implicitly. It's the inverse of C++'s `explicit` keyword.
As such, @implicit is overwhelmingly useful in its own right.
This will address my single biggest usability complaint of D as
compared to C++. @implicit is super awesome, and we must embrace it.
Re: Copy Constructor DIP and implementation
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 any kind inference here. If we were going to do that, we wouldn't be adding the attribute in the first place. Andrei has a bad score in understanding what is best for language. It's too arrogant, or scary, to listen to anyone: that's about this ... https://www.youtube.com/watch?v=KAWA1DuvCnQ For mockery, I would like to point out that the speaker of this proposal has also exchanged "nogc" for "@nogc": throw the fears into the sea, and fix the total nonsense that this language has become. Best wishes to the moderator.
Re: Copy Constructor DIP and implementation
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 when applied to a function that isn't a ctor. Either it should be made illegal, or the spec should clearly state that it's ignored. - I prefer the former option, because that minimizes the risk of conflicts in the future if we were to expand the scope of @implicit to other language constructs. - However, the latter option is safer in that if existing user code uses @implicit with a different meaning, the first option would cause code breakage and require the user to replace all uses of @implicit with something else. - The DIP needs to address what a copy ctor might mean in a situation with unions, and/or whether it's legal to use unions with copy ctors. There are a few important cases to consider (there may be others): - Should copy ctors even be allowed in unions? - The copy ctor is defined in the union itself. - The union contains fields that have copy ctors. If two overlapping fields have copy ctors, which ctor will get called? Should this case be allowed, or made illegal? - How would type qualifiers (const, immutable, etc.) interact with unions of the above two cases? - If a struct contains a union, and another non-union field that has a copy ctor, how should the compiler define the generated copy ctor of the outer struct? - If a struct declares only one copy ctor, say mutable -> mutable, then according to the DIP (under the section "copy constructor call vs. standard copying (memcpy)"), declaring an immutable variable of that type will default to standard copying instead. - This means if the struct needs explicit handling of copying in a copy ctor, the user must remember to write all overloads of the copy ctor, otherwise there will be cases where standard copying is silently employed, bypassing any user-defined semantics that may be necessary for correct copying. - Shouldn't there be a way for the compiler to automatically generate this boilerplate code instead? Should there be a way to optionally generate warnings in such cases, so that the user can be aware in case default copying isn't desired? - What should happen if the user declares a copy ctor as a template function? Should the compiler automatically use that template to generate const/immutable/etc. copy ctors when needed? T -- Change is inevitable, except from a vending machine.
Re: Copy Constructor DIP and implementation
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 downright > > weird, but if we're going to have one, if we go with @implicit, > > we're future-proofing things a bit, and personally, thinking > > about it over time, I've found that it feels less like a hack > > than something like @copy would. If we had @copy, this would > > clearly forever be something that we added just because we has > > postblit constructors first, whereas @implicit at least _might_ > > be used for something more. > > That does actually make a lot of sense. Isn't there any way these > constructors could be inferred without the attribute? As I understand it, the entire point of the attribute is to avoid any breakage related to constructors that have a signature that matches what a copy constructor would be. If we didn't care about that, there would be no reason to have an attribute. Personally, I think that the concerns about such possible breakage are overblown, because it really wouldn't make sense to declare a constructor with the signature of a copy constructor unless you intended to use it as one (though right now, it would have to be called explicitly). And such code shouldn't break if "explicit" copy constructors then become "implicit" copy constructors automatically. 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 any kind inference here. If we were going to do that, we wouldn't be adding the attribute in the first place. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 personally, thinking about it over time, I've found that it feels less like a hack than something like @copy would. If we had @copy, this would clearly forever be something that we added just because we has postblit constructors first, whereas @implicit at least _might_ be used for something more. That does actually make a lot of sense. Isn't there any way these constructors could be inferred without the attribute?
Re: Copy Constructor DIP and implementation
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 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).
> >>
> >> Also can we really not come up with an alternative bit of code
> >> than the tupleof to copying wholesale? E.g. super(other);
> >
> > I could not agree more. @implicit can mean many things, while
> > @copy is much more specific... For what is worth I vote for
> > @copy ! :)
>
> @implicit makes sense if extending explicitly implicit calls to
> all other constructors gets somday considered. Some people argued
> for it and I agree with them that it'd be nice to have, for ex.
> to make a custom string struct type usable without having to
> smear the code with constructor calls.
That's why some argued in a previous thread on the topic that we should
decide what (if anything) we're going to do with adding implicit
construction to the language before finalizing this DIP. If we added some
sort of implicit constructor to the language, then @implicit would make some
sense on copy constructors (it's still a bit weird IMHO, but it does make
some sense when explained), and in that case, having used @copy could
actually be a problem.
If we're looking at this as an attribute that's purely going to be used on
copy constructors, then @copy does make more sense, but it's also less
flexible. @implicit could potentially be used for more, whereas @copy really
couldn't - not when it literally means copy constructor.
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 that were
intended to be copy constructors but had to be called explicitly, and that
code would almost certainly be fine if copy constructors then became
implicit, but Andrei seems unwilling to do that. But at least, when start
arguing about that, fact that the work "explicitly" very naturally fits into
that as the description for what a copy constructor would be currently, it
does make more sense that @implicit would be used.
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
personally, thinking about it over time, I've found that it feels less like
a hack than something like @copy would. If we had @copy, this would clearly
forever be something that we added just because we has postblit constructors
first, whereas @implicit at least _might_ be used for something more. It
would still feel weird and hacky if it never was used for anything more, but
at least we'd be future-proofing the language a bit, and @implicit does make
_some_ sense after it's explained, even if very few people (if any) will
initially think that it makes sense.
- Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 excellent
for helping people learn what it is doing (spec lookup).
Also can we really not come up with an alternative bit of code
than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. @implicit can mean many things, while
@copy is much more specific... For what is worth I vote for
@copy ! :)
@implicit makes sense if extending explicitly implicit calls to
all other constructors gets somday considered. Some people argued
for it and I agree with them that it'd be nice to have, for ex.
to make a custom string struct type usable without having to
smear the code with constructor calls.
Re: Copy Constructor DIP and implementation
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!
Re: silly is released - new test runner for the D programming language
On Wednesday, 12 September 2018 at 04:02:14 UTC, Soulsbane wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Hello, I'm glad to announce that silly v0.0.1 is released. Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments. In my local version I've modified the test name to be colorized. Could you add this feature? it really helps the readability in my opinion. I doubt that will make it more readable, in fact it'd annoy me. Another thing to consider is the fact that colours in terminal are highly customizable so if something works and most importantly looks good for somebody it might look terrible and be unreadable on different terminal preferences. This is something I experienced with trial which colours test names white and vibe-core's logger which used different shades of grey for different log levels. Both of these as you can imagine are unreadable on black-on-white terminals. Either way, I really love silly! Thanks a lot! You are welcome!
Re: [OT] My State is Illegally Preventing Me From Voting In The Upcoming 2018 US Elections
On Sunday, 9 September 2018 at 14:27:45 UTC, Abdulhaq wrote: If you're serious then why not request an absentee ballot? Just out of curiosity, how does posting this info here help you in any way? I was kind of wondering this too and in worst case a technical error as described is not really his state illegally preventing him from voting. Could be a simple mistake. Contacting his state could probably give him what information he needs to know etc.
Re: Copy Constructor DIP and implementation
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).
Also can we really not come up with an alternative bit of code
than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. @implicit can mean many things, while
@copy is much more specific... For what is worth I vote for @copy
! :)
Re: Copy Constructor DIP and implementation
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 the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it! Thanks, RazvanN [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688 I'm not sure about the naming of `@implicit` attribute. It seems confusing when used. `@copy` feels more natural or do we even need a new attribute at all?
