Re: Copy Constructor DIP and implementation
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, > >>> > >>> 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, > >>> RazvanN > >>> > >>> [1] https://github.com/dlang/DIPs/pull/129/ > >> > >> I've made all the changes in the code that the DIP includes[1] > >> and the tests seem to be all green. I still need to add more > >> tests; if you have any tests that you want to make sure the > >> implementation takes into account please post them. > >> > >> Cheers, > >> RazvanN > >> > >> [1] https://github.com/dlang/dmd/pull/8688 > > > > 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. Immediately after the > DIP is accepted, the postblit will be deprecated. Even without a transitional switch, I would ask that we _please_ delay actually deprecating postblit constructors until copy constructors have been in at least one release. We do this when replacing old symbols in Phobos with new ones, because if we don't, it's not possible to have your code compile with the current release and master at the same time without getting deprecation messages (while code _could_ use static if with __VERSION__ to support multiple releases, that doesn't work with master, since unfortunately, __VERSION__ on master always matches the most recent release rather than the next one). The DIP that covers deprecations talks about delaying deprecations when adding new symbols that for exactly that reason, and replacing postblit constructors with copy constructors poses exactly the same problem. It should always be possible to make code compile with both master and the latest release without deprecation messages, since otherwise, even programmers who are completely on top of things could end up having to deal with a flood of deprecation messages that they can't fix. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 DIP is accepted, the postblit will be deprecated. Its not about the deprecation process, its about the transitional process, i.e what to do when there is both a postblit and a copy constructor are defined. Whatever the default is, if there is no way to control it, it is impossible to transition smoothly.
Re: Copy Constructor DIP and implementation
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 copy is made. For more details, please visit [1] and if you have the time, please offer some feedback, Thank you, RazvanN [1] https://github.com/dlang/DIPs/pull/129/ I've made all the changes in the code that the DIP includes[1] and the tests seem to be all green. I still need to add more tests; if you have any tests that you want to make sure the implementation takes into account please post them. Cheers, RazvanN [1] https://github.com/dlang/dmd/pull/8688 Both the DIP and the implementation still lack a -dip10xx switch.
Re: Copy Constructor DIP and implementation
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 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, RazvanN [1] https://github.com/dlang/DIPs/pull/129/ I've made all the changes in the code that the DIP includes[1] and the tests seem to be all green. I still need to add more tests; if you have any tests that you want to make sure the implementation takes into account please post them. Cheers, RazvanN [1] https://github.com/dlang/dmd/pull/8688 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. Immediately after the DIP is accepted, the postblit will be deprecated.
Re: Copy Constructor DIP and implementation
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 you have the time, please offer some feedback, Thank you, RazvanN [1] https://github.com/dlang/DIPs/pull/129/ I've made all the changes in the code that the DIP includes[1] and the tests seem to be all green. I still need to add more tests; if you have any tests that you want to make sure the implementation takes into account please post them. Cheers, RazvanN [1] https://github.com/dlang/dmd/pull/8688
Re: Copy Constructor DIP and implementation
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, RazvanN [1] https://github.com/dlang/DIPs/pull/129/
Re: Copy Constructor DIP and implementation
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 constructors. I will update the DIP with more information. Also, regarding the cohabitation between postblit and copy constructor: in order to make the transition smoother, whenever a postblit and a copy constructor are found togheter in a struct, the former is used and the latter is ignored (even if it is a field postblit). Once the postblit is going to be deprecated we can do the opposite and use the copy constructor and ignore the postblit. If @implicit is going to be introduced then that is going to be a DIP on its own. Thanks! I still think a -dip10xx flag to control which to prefer is worth doing, since a) it won't be hard to do and will make the transition smoother still , and b) IIRC the motivating factor for this is memory safety. Delaying memory safety while waiting for a deprecation period to expire ( O(years) ) for code that wants to remain backwards compatible with older compiler versions is not something we should be encouraging. In the deprecation period if no flag is given prefer postblit to copy if both are defined, if flag is given prefer copy over postblit. Nic
Re: Copy Constructor DIP and implementation
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 this(ref $q1 S rhs) $q2 as copy constructors. I will update > the DIP with more information. > > Also, regarding the cohabitation between postblit and copy > constructor: in order to make the transition smoother, whenever a > postblit and a copy constructor are found togheter in a struct, > the former is used and the latter is ignored (even if it is a > field postblit). Once the postblit is going to be deprecated we > can do the opposite and use the copy constructor and ignore the > postblit. > > If @implicit is going to be introduced then that is going to be a > DIP on its own. Yay! Thank you. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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, @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 > > > self-justify expansion of @implicit as intended without a separate and > > > time-consuming fight, which is actually the true value of this DIP! > > > > @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.), they're going to have a bug in their program. > > perhaps a rule where declaring a copy-ctor WITHOUT @explicit emits a > compile error...? That would pretty much defeat the whole purpose of why @implicit was added to the DIP in the first place. It's just that it would turn the feared silent code breakage into a compiler error. So, I suppose that it would be an improvement, but it's the sort of thing that would have to go behind a transitional compiler switch, and as soon as we do that, why have @implicit on copy constructors at all? It makes far more sense to use a transitional compiler switch to simply sort out the problem with the potential (but highly unlikely) silent breakage and not do anything with @implicit with copy constructors whatsoever. It avoids having to put a useless attribute on copy constructors forever, and it avoids any potential bugs. Then we can have a separate DIP that deals with @implicit and non-copy constructors for implicit construction. And maybe we do ultimately end up with @implicit on constructors in D. But if @implicit ends up on copy constructors, at best, it's going to be a language wort, since it adds zero value there, but as the DIP currently stands, it's going to be a source of bugs. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 @implicit, allowing it will > > satisfy that there's not a breaking change, it it will also > > self-justify expansion of @implicit as intended without a separate and > > time-consuming fight, which is actually the true value of this DIP! > > @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.), > they're going to have a bug in their program. perhaps a rule where declaring a copy-ctor WITHOUT @explicit emits a compile error...?
Re: Copy Constructor DIP and implementation
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 use it > > (which plenty of programmers will forget, just like they forget > > to use @safe, pure, nothrow, etc.), they're going to have a bug > > in their program. However, unlike, with attributes like @safe > > or pure, they're not going to get a compiler error in their > > program; they're going to get a logic error. They may or may > > not find that bug quickly, but the compiler isn't going to > > point it out to them. > > I think this is the most important reason. In C++, where > everything is implicit by default (which is bad) and (I think) > you are encouraged to use explicit where possible, you should > never use it for the copy constructor because the compiler always > calls it implicitly for you and is the whole point of having: > > Foo a; Foo b = a; > > do something useful. Putting explicit on the copy ctor means that > no longer works, one can then only use it with > > Foo a; Foo b(a); > > Having `Foo a; Foo b = a;` do something completely different by > the addition or removal of one attribute is a serious problem > just waiting to happen. The key thing with explicit in C++ is to avoid issues with implicit conversions between types. You can get weird junk like where int foo(string s); foo(42); compiles, because you have a type A with an implicit constructor which takes int, and an implicit conversion to string. Even though A isn't explicitly used here anywhere, because it's available, and no more than three conversions are required to go from int to string when using A, the compiler will use A to from int to string. That probably isn't what the programmer wanted, but the compiler will happily do it. Because of this, it's best practice in C++ to put explicit on any constructors which take other types where you don't explicitly want the implicit conversion in order to try to avoid this conversion mess. You then only leave explicit off of constructors where you want the implicit conversion or constructors where it's unnecessary (e.g. default constructors or copy constructors). D avoids this mess by simply not having any kind of implicit construction. It just has implicit conversion via alias this. It may or may not be worth adding implicit construction via something like @implicit, but it would at least then only be on constructors which were explicitly marked with @implicit, whereas with C++, you have to use explicit to turn off the behavior. So, in C++, it's a total mess by default, whereas in D, we'd only have it where the programmer asked for it. And presumably, any DIP that added it wouldn't have the compiler do more than one conversion at a time, whereas as I understand it, C++ allows the compiler to do up to three conversions in order to make a piece of code work. But ultimately, such details will have to be decided with such a DIP. Either way, none of this has anything to do with copy constructors. It makes no sense to have copy constructors that require that you call them explicitly. And while it would be bad enough if the DIP required that you mark copy constructors with @implicit for them to work as copy constructors and then didn't have implicit copying without @implicit, that's not what it does. Instead, what it does when you forget @implicit is revert to the default copy semantics, meaning that you have a copy constructor that needs to be called explicitly, but you didn't realize that it needed to be called explicitly, and you're blindly using the default copy semantics rather than the copy constructor. So, the semantics that the DIP describes are just plain a recipe for bugs. But since the PR has been updated to remove @implicit, maybe the DIP will be updated to remove it as well, and the whole @implicit discussion can be left to a future DIP on implicit construction and left out of copy construction entirely. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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.), they're going to have a bug in their program. However, unlike, with attributes like @safe or pure, they're not going to get a compiler error in their program; they're going to get a logic error. They may or may not find that bug quickly, but the compiler isn't going to point it out to them. I think this is the most important reason. In C++, where everything is implicit by default (which is bad) and (I think) you are encouraged to use explicit where possible, you should never use it for the copy constructor because the compiler always calls it implicitly for you and is the whole point of having: Foo a; Foo b = a; do something useful. Putting explicit on the copy ctor means that no longer works, one can then only use it with Foo a; Foo b(a); Having `Foo a; Foo b = a;` do something completely different by the addition or removal of one attribute is a serious problem just waiting to happen.
Re: Copy Constructor DIP and implementation
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 > self-justify expansion of @implicit as intended without a separate and > time-consuming fight, which is actually the true value of this DIP! @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.), they're going to have a bug in their program. However, unlike, with attributes like @safe or pure, they're not going to get a compiler error in their program; they're going to get a logic error. They may or may not find that bug quickly, but the compiler isn't going to point it out to them. And if @implicit weren't a thing, then the problem wouldn't even exist. @implicit is trying to get around breaking an extremely unlikely piece of code which would be far better fixed by using a transitional compiler flag and which adds _no_ value for copy constructors in the long run. Even if we do later add @implicit to the language for regular constructors, it has no business on copy constructors. And its value on other constructors needs to be evaluated and examined on its own separately from the issue of copy constructors. We should not be letting @implicit be put onto copy constructors just to get it into the language. If it's such a valuable feature on regular constructors, it should be able to get in on a separate DIP specifically for that purpose without piggybacking in on the copy constructor DIP - especially when it's clearly going to be a source of bugs if it's required to be on copy constructors. And it just needlessly adds to the attribute soup. At least if it were added for regular constructors, it would be adding value. For copy constructors, it's just adding annoyance and the risk of bugs. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 exists at all and in most cases would continue to work just > > fine even if it did exist. > > > > - Jonathan M Davis > > I somewhat agree with this argument, but overall I hate this > attitude of "we should just make the change because it *probably* > won't break any code", and then bonus points for "code that does > this is wrong anyway so we shouldn't care if we break it". I've > already been burned by that a couple times using D, and I imagine > heavy corporate users with large code bases have many more > problems with this. In this particular case, a transitional compiler flag like we've done with other DIPs makes _far_ more sense than forcing everyone to use an attribute forever - especially when forgetting to use the attribute is going to be a further source of bugs, one which would _easily_ outweigh any code breakage caused by not having the attribute. But having a transitional compiler flag would give us a way to deal with the potential code breakage if it exists. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 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. > > > > @implicit is desperately needed (just not for copy > > constructors!). Do you have confidence that an @implicit > > proposal will happen if you all insist that it's removed here? > > This is a great driving motivator to support @implicit's > > introduction. > > If we are going to introduce the keyword/attribute implicit then > it needs its own DIP. As of now, this DIP have a very weak > justification for it. I certainly agree; I'm fairly sure I produced the very first critical comment on this issue when it first landed, which went like "@implicit is a dependency and needs a dependent dip", which Andrei brushed off. I still believe it's a separate feature, and it's a dependency for this particular DIP, so that should come first... but here's the thing; that's just not how dlang works around here. We like the idea that there's process and structure, but there's not, and you just need to be practical about maneuvering towards the goals you want in the ways that manifest. In this case, having @implicit is a very real and desirable goal, it's been a sore hole in the language since ever... so anything that moves it towards reality is preferable to nothing. While I felt strongly about my conviction initially (that there should be a dependent DIP), I realised that a much more useful and practical position was to allow this dip to introduce @implicit implicitly (heh)... that's a much better reality than waiting an addition year or 2 (if ever!) for the thing otherwise. I encourage people to consider this holistically and consider the practicality of allowing it, even thought it's not a strictly principled in terms of process ;) 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 self-justify expansion of @implicit as intended without a separate and time-consuming fight, which is actually the true value of this DIP!
Re: Copy Constructor DIP and implementation
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 yet from the DIP. > > https://github.com/dlang/dmd/commit/cdd8100 Good, It's not needed. @implicit is desperately needed (just not for copy constructors!). Do you have confidence that an @implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support @implicit's introduction. If we are going to introduce the keyword/attribute implicit then it needs its own DIP. As of now, this DIP have a very weak justification for it. -Alex
Re: Copy Constructor DIP and implementation
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. > > > > https://github.com/dlang/dmd/commit/cdd8100 > > Good, It's not needed. @implicit is desperately needed (just not for copy constructors!). Do you have confidence that an @implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support @implicit's introduction.
Re: Copy Constructor DIP and implementation
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 M Davis I somewhat agree with this argument, but overall I hate this attitude of "we should just make the change because it *probably* won't break any code", and then bonus points for "code that does this is wrong anyway so we shouldn't care if we break it". I've already been burned by that a couple times using D, and I imagine heavy corporate users with large code bases have many more problems with this.
Re: Copy Constructor DIP and implementation
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.
Re: Copy Constructor DIP and implementation
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: > >> [...] > > > > 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 is > > pretty irrelevant. And keywords eat up identifiers, so they're > > actually worse. > > > > In addition, most of the complaints about @implicit have to do > > with the fact that it doesn't even add anything. It's annoying > > that we have @nogc, @safe, pure, etc. but at least each of > > those adds something. @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 M Davis > > It appears that @implicit has been removed from the > implementation [1], but not yet from the DIP. > > https://github.com/dlang/dmd/commit/cdd8100 Well, that's a good sign. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 is pretty irrelevant. And keywords eat up identifiers, so they're actually worse. In addition, most of the complaints about @implicit have to do with the fact that it doesn't even add anything. It's annoying that we have @nogc, @safe, pure, etc. but at least each of those adds something. @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 M Davis It appears that @implicit has been removed from the implementation [1], but not yet from the DIP. https://github.com/dlang/dmd/commit/cdd8100
Re: Copy Constructor DIP and implementation
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 > > attributes, this will undoubtedly adding more to it. > > When I (and surely others like me) complain that there are too > many attributes, the complaint has nothing to do with the @ > character. I consider "nothrow" and "pure" to be part of the > problem and they lack @. 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 is pretty irrelevant. And keywords eat up identifiers, so they're actually worse. In addition, most of the complaints about @implicit have to do with the fact that it doesn't even add anything. It's annoying that we have @nogc, @safe, pure, etc. but at least each of those adds something. @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 M Davis
Re: Copy Constructor DIP and implementation
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 there are too many attributes, the complaint has nothing to do with the @ character. I consider "nothrow" and "pure" to be part of the problem and they lack @.
Re: Copy Constructor DIP and implementation
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] 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 The only thing I object is adding yet another attribute to a already big bag of attributes. What's wrong with adding keywords? -Alexander I initially felt strongly against @implicit, it shouldn't be necessary, and we could migrate without it. But... assuming that @implicit should make an appearance anyway (it should! being able to mark implicit constructors will fill a massive usability hole in D!), then it doesn't hurt to use it eagerly here and avoid a breaking change at this time, since it will be the correct expression for the future regardless. 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. -Alexander
Re: Copy Constructor DIP and implementation
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 supposed to be for in that pragmas are supposed to be compiler-specific, not really part of the language. [...] I totally agree with this.
Re: Copy Constructor DIP and implementation
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 @implicit. In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with @implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis What about a command-line switch that just detects copy constructors? LLVM 8 supposedly has a new feature which breaks compatibility for casts from float -> int: Floating-point casts—converting a floating point number to an integer by discarding the data after the decimal—has been optimized, but in a way that might cause problems for developers who rely on undefined behavior around this feature. Clang has a new command-line switch to detect this issue. Could we do copy-constructors in a similar way?
Re: Copy Constructor DIP and implementation
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 @implicit. In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with @implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis Well one breaks compilation and the other is silent code changes. And No.compilerSwitch > Yes.compilerSwitch when possible. I'm actually not strongly for @implicit btw.
Re: Copy Constructor DIP and implementation
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 @implicit.
In that case, why not just use a transitional compiler switch?
Why force everyone to mark their copy constructors with
@implicit forever? The whole point of adding the attribute was
to avoid breaking existing code.
- Jonathan M Davis
Apparently because extending copy constructors are intended to be
extended to types other than typeof(this), which would also be
implicit, and then @implicit is to make sure that you actually
want this(ref SomethingElse){ ... } to be implicitly called when
A a;
B b;
...
b = a;
which I think is a bad idea, not the least of which is because
thats what opAssign is for.
See https://github.com/dlang/DIPs/pull/129#discussion_r218006614
Re: Copy Constructor DIP and implementation
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 force everyone to mark their copy constructors with @implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 constructors will require it is just going to
cause bugs, because plenty of folks are going to forget to use
it and end up with the default copying behavior instead of
their custom copy constructor being used. Good testing should
find that pretty quickly, but it's almost certainly going to be
a common bug, and it has no need to exist. It's all there in
order to avoid breaking code that's likely only theoretical and
not something that actual D code bases have done. And if there
is a stray code base that did it, it's certainly going to be in
the extreme minority, and the code will almost certainly work
as a proper copy constructor anyway, since that's pretty much
the only reason to write such a constructor. So, we'd be trying
to avoid breaking very rare code by introducing a feature that
will definitely cause bugs. IMHO, it would be _far_ better to
just use a transitional -dip* compiler flag like we have with
other DIPs. It would also give us the benefit of being able to
bang on the implementation a bit before making it the normal
behavior.
We can still add @implicit to other constructors for implicit
construction with a later DIP (assuming that Walter and Andrei
could be convinced of it). I don't see how having it on copy
constructors really helps with that. It just means that the
attribute would already be there, not that it would necessarily
ever be used for what you want, and _not_ having it on copy
constructors wouldn't prevent it from being used for implicit
construction if such a DIP were ever accepted. So, while I
understand that you want implicit construction, I think that
it's a huge mistake to tie that up into copy constructors,
particularly since it really doesn't make sense to have copy
constructors that aren't implicit, and having @implicit for
copy constructiors is going to cause bugs when it's forgotten.
- Jonathan M Davis
I think this can be made in to a compiler error.
The logic would be if there is any copy constructor defined (by
copy constructor I mean a constructor that gets passed an object
that can be used to construct typeof(this) - so ignore definition
in DIP), then default copy construction is a compiler error
unless an @implicit copy constructor is defined.
struct A {
this(ref A) {}
}
A a;
A b = a; // error, cannot implicitly copy because an explicit one
is provided
A c = A(a); // ok
This will break compilation of current code that has an explicit
copy constructor, and the fix is simply to add the attribute
@implicit.
Re: Copy Constructor DIP and implementation
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
That's why it exists, otherwise I wouldn't want two types to be
implicitly convertible unless i explicitly tell it to be
implicit.
This DIP does not allow this, but apparently it is on the
horizon[1],
it will be easier to extend the feature to copy construct
from any type to any type
Is this a thing we are even considering?
Yes.
I don't agree with it.
[1]: https://github.com/dlang/DIPs/pull/129#discussion_r218006614
Re: Copy Constructor DIP and implementation
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 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 > > > > The only thing I object is adding yet another attribute to a > > already big bag of attributes. What's wrong with adding keywords? > > > > -Alexander > > I initially felt strongly against @implicit, it shouldn't be > necessary, and we could migrate without it. > But... assuming that @implicit should make an appearance anyway (it > should! being able to mark implicit constructors will fill a massive > usability hole in D!), then it doesn't hurt to use it eagerly here and > avoid a breaking change at this time, since it will be the correct > expression for the future regardless. Except that @implicit could be introduced for other constructors without having it on copy constructors, and the fact that copy constructors will require it is just going to cause bugs, because plenty of folks are going to forget to use it and end up with the default copying behavior instead of their custom copy constructor being used. Good testing should find that pretty quickly, but it's almost certainly going to be a common bug, and it has no need to exist. It's all there in order to avoid breaking code that's likely only theoretical and not something that actual D code bases have done. And if there is a stray code base that did it, it's certainly going to be in the extreme minority, and the code will almost certainly work as a proper copy constructor anyway, since that's pretty much the only reason to write such a constructor. So, we'd be trying to avoid breaking very rare code by introducing a feature that will definitely cause bugs. IMHO, it would be _far_ better to just use a transitional -dip* compiler flag like we have with other DIPs. It would also give us the benefit of being able to bang on the implementation a bit before making it the normal behavior. We can still add @implicit to other constructors for implicit construction with a later DIP (assuming that Walter and Andrei could be convinced of it). I don't see how having it on copy constructors really helps with that. It just means that the attribute would already be there, not that it would necessarily ever be used for what you want, and _not_ having it on copy constructors wouldn't prevent it from being used for implicit construction if such a DIP were ever accepted. So, while I understand that you want implicit construction, I think that it's a huge mistake to tie that up into copy constructors, particularly since it really doesn't make sense to have copy constructors that aren't implicit, and having @implicit for copy constructiors is going to cause bugs when it's forgotten. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 constructor if D had them instead of postblit constructors
> > and that that code would break with the DIP. Does anyone expect
> > that such a constructor would be intended as anything other
> > than a copy constructor (albeit one that has to be called
> > explicitly)? And does anyone really think that such
> > constructors are at all common, given that the correct way to
> > handle the problem in D right now is the postblit constructor?
> > 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 it's all to avoid
> > breaking a theoretical piece of code that I would think that we
> > could all agree is extremely rare if it exists in any real D
> > code base at all. Simply using a transitional compiler switch
> > like we have with other DIPs would make _way_ more sense than
> > burdening the language with an unnecessary attribute that's
> > just going to make it easier to write buggy code. This is
> > clearly a case of making the language worse long term in order
> > to avoid a theoretical problem in the short term.
> >
> > - Jonathan M Davis
>
> 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
>
> That's why it exists, otherwise I wouldn't want two types to be
> implicitly convertible unless i explicitly tell it to be implicit.
No. That wouldn't be a copy constructor. The DIP specifically says that "A
declaration is a copy constructor declaration if it is a constructor
declaration annotated with the @implicit attribute and takes only one
parameter by reference that is of the same type as typeof(this)." So, it
clearly must be the same type and can't be a different type.
It also says that "The copy constructor needs to be annotated with @implicit
in order to distinguish a copy constructor from a normal constructor and
avoid silent modification of code behavior." Andrei confirmed that that's
why @implicit was there in the last major discussion on the DIP in the
newsgroup. So, it's clearly there in order to avoid breaking existing code -
code which is going to be _extremely_ rare.
- Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 DIP. Does anyone expect
that such a constructor would be intended as anything other
than a copy constructor (albeit one that has to be called
explicitly)? And does anyone really think that such
constructors are at all common, given that the correct way to
handle the problem in D right now is the postblit constructor?
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 it's all to avoid
breaking a theoretical piece of code that I would think that we
could all agree is extremely rare if it exists in any real D
code base at all. Simply using a transitional compiler switch
like we have with other DIPs would make _way_ more sense than
burdening the language with an unnecessary attribute that's
just going to make it easier to write buggy code. This is
clearly a case of making the language worse long term in order
to avoid a theoretical problem in the short term.
- Jonathan M Davis
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
That's why it exists, otherwise I wouldn't want two types to be
implicitly convertible unless i explicitly tell it to be implicit.
Re: Copy Constructor DIP and implementation
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 > > 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 > > The only thing I object is adding yet another attribute to a > already big bag of attributes. What's wrong with adding keywords? > > -Alexander I initially felt strongly against @implicit, it shouldn't be necessary, and we could migrate without it. But... assuming that @implicit should make an appearance anyway (it should! being able to mark implicit constructors will fill a massive usability hole in D!), then it doesn't hurt to use it eagerly here and avoid a breaking change at this time, since it will be the correct expression for the future regardless.
Re: Copy Constructor DIP and implementation
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 > > 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 > > The only thing I object is adding yet another attribute to a > already big bag of attributes. What's wrong with adding keywords? Every keyword that gets added is one more word that can't be used for identifiers, which we don't want to do without a really good reason, and in this particular context, I don't see what it would buy you anyway. You'd just end up not having to put @ in front of it - and then of course, that word couldn't be used as an identifier anymore. So, overall, going with a keyword over an attribute seems like a net negative. IMHO, the core problem is that the DIP adds _anything_ that you have to mark up copy constructors with. We should just have a -dip* flag as a transition to deal with the theoretical breakage that @implicit is supposed to prevent (as well as gives us a chance to kick the tires of the implementation a bit first) and not do anything special to mark copy constructors aside from what their parameters are. - Jonathan M Davis
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 The only thing I object is adding yet another attribute to a already big bag of attributes. What's wrong with adding keywords? -Alexander
Re: Copy Constructor DIP and implementation
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 it's all to avoid breaking a theoretical piece of code that I would think that we could all agree is extremely rare if it exists in any real D code base at all. Simply using a transitional compiler switch like we have with other DIPs would make _way_ more sense than burdening the language with an unnecessary attribute that's just going to make it easier to write buggy code. This is clearly a case of making the language worse long term in order to avoid a theoretical problem in the short term. - Jonathan M Davis Completely agree.
Re: Copy Constructor DIP and implementation
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 > > 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 > > If @implicit is the contentious part of this DIP, maybe it would > be a good idea for us to instead use a `pragma(copyCtor)` or the > like to avoid having to add another attribute while preserving > backward-compatibility. Like @implicit, it's very easy to turn > existing constructors into copy constructors just by adding the > pragma, and they can be added to code with impunity because even > older versions of the compiler will just ignore pragmas they > don't recognize. 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 supposed to be for in that pragmas are supposed to be compiler-specific, not really part of the language. The core problem is that no such attribute or pragma should be necessary in the first place. It makes no sense to have a copy constructor that must be called explicitly, and if we have to use an attribute (or pragma or anything else) to optionally mark the copy constructor as a copy constructor, then it's something that people are going to forget to do at least some portion of the time, causing bugs. It also seems downright silly to have an attribute (or pragma or whatever) that you have to _always_ use. No one is going to be purposefully writing copy constructors that aren't "implicit." So, they're _all_ going to have to have it. It would be like having to mark all destructors with an attribute just so that they'd be treated as destructors. It's something that's simply inviting bugs, because at least some of the time, programmers will forget to use the attribute. 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 DIP. Does anyone expect that such a constructor would be intended as anything other than a copy constructor (albeit one that has to be called explicitly)? And does anyone really think that such constructors are at all common, given that the correct way to handle the problem in D right now is the postblit constructor? 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 it's all to avoid breaking a theoretical piece of code that I would think that we could all agree is extremely rare if it exists in any real D code base at all. Simply using a transitional compiler switch like we have with other DIPs would make _way_ more sense than burdening the language with an unnecessary attribute that's just going to make it easier to write buggy code. This is clearly a case of making the language worse long term in order to avoid a theoretical problem in the short term. - Jonathan M Davis
Re: Copy Constructor DIP and implementation
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 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. [snip] > > - Jonathan M Davis > > I'd also vote for no attribute for copy constructors and have a > tool to warn us of changes across compiler versions that can > detect constructors that look like copy constructors. > > If dub keeps track of the dmd compiler version we could even have > automated warnings for all dub packages. > > This would also start us on the road towards a tool that allows > us to make breaking changes. At first the tool could just warn > us. Then we could slowly add automated code transforms. > > Pretty sure this sort of tool has been mentioned before. This > seems like a good use-case. At minimum, we could use a transitionary compiler flag like we have with other DIPs. - Jonathan M Davis
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 If @implicit is the contentious part of this DIP, maybe it would be a good idea for us to instead use a `pragma(copyCtor)` or the like to avoid having to add another attribute while preserving backward-compatibility. Like @implicit, it's very easy to turn existing constructors into copy constructors just by adding the pragma, and they can be added to code with impunity because even older versions of the compiler will just ignore pragmas they don't recognize.
Re: Copy Constructor DIP and implementation
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 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. [snip] - Jonathan M Davis I'd also vote for no attribute for copy constructors and have a tool to warn us of changes across compiler versions that can detect constructors that look like copy constructors. If dub keeps track of the dmd compiler version we could even have automated warnings for all dub packages. This would also start us on the road towards a tool that allows us to make breaking changes. At first the tool could just warn us. Then we could slowly add automated code transforms. Pretty sure this sort of tool has been mentioned before. This seems like a good use-case. R
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: 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?
Re: Copy Constructor DIP and implementation
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!
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? 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 can keep the same syntax and annotations, and it will be consistent. Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other); That would be possible, but it would be inconsistent with super constructors in general.
Re: Copy Constructor DIP and implementation
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 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
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);
Re: Copy Constructor DIP
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, Manu wrote: > >>> > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via > >>> > Digitalmars-d wrote: > >>> >> > >> [..] > >> doesn't perform copy construction? > >> 1. the function is highly unlikely to exist because > >> postblit; it's a > >> meaningless function to write. are there any known instances > >> of that > >> signature in the wild? > > > > https://github.com/search?q=%22this%5C%28ref%22+language%3AD=Code > > > > The answer seems to be: not many. Most of the results above are > > false positives because github won't let me escape the left > > parenthesis. > > > > Atila > > https://www.google.no/search?q=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad I clicked through quite a few. Every function that's a valid copy constructor by the definition here does indeed perform a valid copy construction with no side-effects, as predicted. Existing functions interpreted as copy constructors under this DIP would continue to work as intended. There's a ridiculously low probability that any such wild function that would be broken by a no-attribute version of this DIP exists.
Re: Copy Constructor DIP
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 wrote: >> [..] doesn't perform copy construction? 1. the function is highly unlikely to exist because postblit; it's a meaningless function to write. are there any known instances of that signature in the wild? https://github.com/search?q=%22this%5C%28ref%22+language%3AD=Code The answer seems to be: not many. Most of the results above are false positives because github won't let me escape the left parenthesis. Atila https://www.google.no/search?q=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad
Re: Copy Constructor DIP
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! Thank you!
Re: Copy Constructor DIP
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 normal symbol. So the normal
lookup rules apply. In particular, you can shadow an imported `implicit`
with a local one:
--- object.d
enum implicit = 1; /* Actual implementation would be different. */
--- bar.d
/* invisible default `import object` here */
@implicit void f() {}
static assert(__traits(getAttributes, f)[0] == 1);
/* Passes. `object.implicit` is used. */
--- baz.d
/* invisible default `import object` here */
enum implicit = 2;
@implicit void f() {}
static assert(__traits(getAttributes, f)[0] == 2);
/* Passes. The local `implicit` is used. */
You can't do that with `@safe`, because `@safe` is not a UDA, and `safe`
is not a symbol there. `@safe` is special syntax, recognized as a whole
by the parser. No symbol lookup is happening.
You can see the difference if you change all occurrences of "implicit"
to "safe" in that code. Won't work.
As for breakage, baz.d is working code today. With `@implicit` as a UDA,
it keeps working in the same way. With `@implicit` as a new non-UDA
attribute, it will change its meaning, and the assert will fail.
Re: Copy Constructor DIP
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 to be followed by more obscure attribute names. And don't get me started about inventing new syntax. Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. 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.) I also think a more general attribute is better. I think there's a middle ground between total analysis paralysis and no discussion of concept generality. I had hoped some thought would be given to the implications of implicit but overall I'm still happy, and I trust your judgement. BTW, I would still have brought it up even if the DIP didn't mention future directions :-)
Re: Copy Constructor DIP
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
Re: Copy Constructor DIP
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 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 want really. > > (What follows is a personal opinion. > > 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 to be followed > by more obscure attribute names. And don't get me started > about inventing new syntax. > > Regarding the hand-wringing over generality: we have an > exceedingly poor record of paralysis of analysis, whereby > we'd worry that every design decision potentially locks us > out from all other as-of-yet-unchosen design decisions. If > history is any indication, this sudden worry about > vaguely-promising green pastures of the future is a sign of > malady. We want copy construction. Conflating this with a > very general schemata for implicit conversion would not be a > wise decision in my opinion. 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.) > > > Andrei I think in this case, a more obscure name like @copyctor is more descriptive. I fear that at some point, a more general attribute like "@implicit" will turn into the next "static". To me, @implicit smells like one of those keywords that will grow to carry many different meanings in different contexts and just end up overly-broad. But that's the point, and the key advantage of the name ;) Aye! And in this case it really is implicit copy construction. With this attribute in the compiler I can also see a future DIP that deprecates implicit construction and requires an explicit @implicit be added to constructors! Which also sounds like a win :D It's not ideal that the implicit attribute does not have a larger discussion around it. But it is nice to something in D where the default is the conservative approach and the more liberal has to be explicitly asked for. And at the same time, at this point it really is an attribute that is only applicable to copy constructors. So how much expansion on that would be enough I wonder? Cheers, - Ali
Re: Copy Constructor DIP
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 does not cause any breaking changes, which is just as easy to do? It also doesn't required any special casing in the parser. This is how @selector is implemented. -- /Jacob Carlborg 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?) Cheers, - Ali
Re: Copy Constructor DIP
On 7/17/18 12:04 AM, Manu wrote: But that's the point, and the key advantage of the name ;) [:nod:]
Re: Copy Constructor DIP
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 does.
Re: Copy Constructor DIP
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? It also doesn't required any special casing in the parser. This is how @selector is implemented. -- /Jacob Carlborg
Re: Copy Constructor DIP
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 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 want really. > > > > (What follows is a personal opinion. > > > > 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 to be followed by > > more obscure attribute names. And don't get me started about > > inventing new syntax. > > > > Regarding the hand-wringing over generality: we have an > > exceedingly poor record of paralysis of analysis, whereby we'd > > worry that every design decision potentially locks us out from > > all other as-of-yet-unchosen design decisions. If history is > > any indication, this sudden worry about vaguely-promising green > > pastures of the future is a sign of malady. We want copy > > construction. Conflating this with a very general schemata for > > implicit conversion would not be a wise decision in my opinion. > > 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.) > > > > > > Andrei > > I think in this case, a more obscure name like @copyctor is more > descriptive. I fear that at some point, a more general attribute > like "@implicit" will turn into the next "static". To me, > @implicit smells like one of those keywords that will grow to > carry many different meanings in different contexts and just end > up overly-broad. > But that's the point, and the key advantage of the name ;)
Re: Copy Constructor DIP
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 attribute a more obscure name such as @copyctor or anything people want really. (What follows is a personal opinion. 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 to be followed by more obscure attribute names. And don't get me started about inventing new syntax. Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. 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.) Andrei I think in this case, a more obscure name like @copyctor is more descriptive. I fear that at some point, a more general attribute like "@implicit" will turn into the next "static". To me, @implicit smells like one of those keywords that will grow to carry many different meanings in different contexts and just end up overly-broad. -Jon
Re: Copy Constructor DIP
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.attribute. This would also avoid any special syntax in the parser. The already existing @selector is implemented like this. Affirmative. We're going that route, similar to "@safe" and "@nogc". @safe and @nogc are not compiler recognized UDAs. If you implement @implicit like them, then you're not doing what Jacob suggests. Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/
Re: Copy Constructor DIP
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 special syntax in the parser. The already existing @selector is implemented like this. Affirmative. We're going that route, similar to "@safe" and "@nogc". @safe and @nogc are not compiler recognized UDAs. If you implement @implicit like them, then you're not doing what Jacob suggests.
Re: Copy Constructor DIP
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
{
@implicit this(ref C another) {}
}
Today, that's a normal constructor. With the DIP, it becomes a copy
constructor.
That is correct and a liability of the current DIP. That should be
mentioned in it.
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 special syntax in
the parser. The already existing @selector is implemented like this.
Affirmative. We're going that route, similar to "@safe" and "@nogc".
Re: Copy Constructor DIP
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 present. Thanks! The difference between a copy constructor and opAssign is how the type checking is performed. This leads to situations where a copy constructor is not suitable as an assignment operator. However, if a copy ... What are your opinions on this? What about going the other way? Can you use the unqualified opAssign as the unqualified copy constructor? I assume these @implicit copy constructors are normal constructors.
Re: Copy Constructor DIP
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, that's a normal constructor. With the DIP, it becomes a
copy constructor.
That is correct and a liability of the current DIP. That should
be mentioned in it.
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 special syntax in the parser. The already existing @selector
is implemented like this.
--
/Jacob Carlborg
Re: Copy Constructor DIP
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. Strongly agree with this. In my review on Github I had a few sentences about this, but I removed them because I thought it may be perceived wrong. I find it almost completely irrelevant to add a "future directions" discussion to a DIP. If a DIP is incomplete, then finish it. Other than that, a DIP should stand completely on its own, regardless of speculation on future directions. -Johan Really any mention of the "future" in a DIP section wise, should be fairly concrete. I.e. this is already a good design, BUT it may come to pass that this use case is indeed important to support (an acknowledgement to its existence) so here is an idea on how to support it. It doesn't need to be entirely thought out, it just needs to be pretty well thought out and with clear added complexity as to why it isn't part of the original DIP. The example I'll use is my named arguments DIP[0], where I show a feature that could be added to allow renaming of args. However, because I'm unconvinced that such a complex feature is even needed, I don't support it. [0] https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md#future-proposals
Re: Copy Constructor DIP
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 had a few sentences about this, but I removed them because I thought it may be perceived wrong. I find it almost completely irrelevant to add a "future directions" discussion to a DIP. If a DIP is incomplete, then finish it. Other than that, a DIP should stand completely on its own, regardless of speculation on future directions. -Johan
Re: Copy Constructor DIP
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 want really. (What follows is a personal opinion. 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 to be followed by more obscure attribute names. And don't get me started about inventing new syntax. Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. 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.) Andrei
Re: Copy Constructor DIP
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 upon a 'yes' answer by me. That an attempt is made for > an alternative syntax discussion. It's a fair request I think. > I just want to reiterate again, I'm not seeking alternative syntax, I just want to know that proposed syntax can work broadly, or if there are any challenges or problems that would restrict it from broad application. >
Re: Copy Constructor DIP
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 @implicit. That
completes the spec of @implicit.
That is the problem: you are using a very generic name
("implicit") to signify both:
1) something very general ("will be callable implicitly by the
compiler") and
2) something very specific ("a constructor that takes by
reference a qualified typeof(this)")
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?
On the other hand, if the name is chosen with the hope that the
meaning will be generalized in the future ("callable implicitly
by the compiler"), why don't you want to at least briefly discuss
that more general meaning?
What happens if you later conclude that a generic "callable
implicitly by the compiler" annotation has semantics that don't
quite align with those of this ctor annotation? Do you need to
introduce @implicitconv?
Surely we want the language constructs to be composable and
generalizable, and not just quirky one offs that you have to
memorize. This seems like a missed opportunity to make sure of
that.
Re: Copy Constructor DIP
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 think.
Re: Copy Constructor DIP
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 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'm the only one that > >> finds problem with that. > > > > You are very much not alone. > > > > I didn't articulate it very clearly, but I am super not happy with such > > a new attribute. > > It's a very simple process - @implicit is not invented as much as a given. > > We need to distinguish a constructor from other constructors. > > The constructor supports attributes. > > Attributes are a mechanism for distinguishing declarations from other > declarations. > > Ergo, an attribute is the mechanism of choice. > > Done deal. > > = > > If we don't like the use of an attribute, it means we somehow failed in > defining attributes in the first place. (I don't think we did; > attributes as defined in D are brilliant and currently underused.) It's > poor language design to define a mechanism for doing a category of Xs > and then explicitly avoiding it exactly when the opportunity of doing X > arises. > > From that vantage point, the choice of an attribute to identify > implicit copy construction is unassailably obvious, and elucubrated > syntax inventions such as "@this", "this(ref this x)" are chucklesomely > profligate and ridiculously baroque. But you surely recognise that D has a lot of intrinsic attributes already, and that's a lot of mental (and visual) baggage to carry around. If we add a new intrinsic attribute, I would want to be sure it's widely useful, because every D user will need to learn about and understand it. It's much easier to learn, and more useful knowledge to have, if it has a broad meaning which solves a general class of problem, than just a marker that you need to remember you have to type in one specific niche location.
Re: Copy Constructor DIP
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 reference a qualified typeof(this) and has the @implicit > attribute will be callable implicitly by the compiler. There is no other > meaning of @implicit. That completes the spec of @implicit. Right, and this is 100% of my concern here. To introduce a new attribute for such a one-off purpose feels like a poor choice, and on those terms I would rather see the feature work with no such attribute (as we've considered in the other fork). If you assess the likelihood of actually breaking code in the wild (I expect it's super slim; data would be nice), you might find that the risk is satisfactory. However, the DIP alludes to a possible future for the attribute, and I think that text is intended to make us feel better about the introduction of the attribute, but I would be a lot more comfortable with a more substantial support of its introduction. Basically, and you already know this; I think it's a weird choice to introduce a new attribute for this one-off case, but as a systemic feature which addresses a general long-standing problem, it feels like a good and logical solution. I think we need some idea if the broader application is even theoretically workable up-front. If there's obvious issues with the idea of deploying @implicit generally, then we shouldn't deploy it here, and instead, we should deploy something else here which CAN successfully be generalised in the future. Determining that requires at least a cursory exploration.
Re: Copy Constructor DIP
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's going to be okay. Or maybe, I'm surprised I'm the only one that finds problem with that. You are very much not alone. I didn't articulate it very clearly, but I am super not happy with such a new attribute. It's a very simple process - @implicit is not invented as much as a given. We need to distinguish a constructor from other constructors. The constructor supports attributes. Attributes are a mechanism for distinguishing declarations from other declarations. Ergo, an attribute is the mechanism of choice. Done deal. = If we don't like the use of an attribute, it means we somehow failed in defining attributes in the first place. (I don't think we did; attributes as defined in D are brilliant and currently underused.) It's poor language design to define a mechanism for doing a category of Xs and then explicitly avoiding it exactly when the opportunity of doing X arises. From that vantage point, the choice of an attribute to identify implicit copy construction is unassailably obvious, and elucubrated syntax inventions such as "@this", "this(ref this x)" are chucklesomely profligate and ridiculously baroque. Andrei
Re: Copy Constructor DIP
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 implicitly by the compiler. There is no other meaning of @implicit. That completes the spec of @implicit. Sadly we got to irreducible positions once again: you and I used different definitions for common terms like "define", "specify", "explain", "contribute", and then you use them to ask questions or make demands, all of which I'm sure you find reasonable. But I am unable to understand them, let alone take them under advisement when working on the DIP. (I did understand your reference to the assignment and will work on that, thanks much.) You will need to forgive me for the scarcity of my future answers - but believe me I will do my best to derive value from your feedback. Andrei
Re: Copy Constructor DIP
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 any sense of where it's going to be okay. Or maybe, I'm surprised I'm the only one that finds problem with that. You are very much not alone. I didn't articulate it very clearly, but I am super not happy with such a new attribute. I'm not crazy about it either, but it may be a necessary evil to avoid breaking code (although it doesn't entirely avoid that, as has been demonstrated).
Re: Copy Constructor DIP
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'm the only one that finds problem with that. You are very much not alone. I didn't articulate it very clearly, but I am super not happy with such a new attribute.
Re: Copy Constructor DIP
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 facts instead of feelings. "It's weird" or "I don't like it" are
> less helpful than "semantics of this or that case are not covered".
What "I don't like" is using an attribute as a marker, and especially
in the unique case of a copy constructor, which is so fundamental to
the language.
If it has a systemic meaning, as it's sort-of proposed that maybe it
might in the future sometime, then it's fine.
There's a lot of subjectivity in programming. I don't like that python
has significant white-space. I don't like that Javascript isn't a
native language.
I don't like the idea of introducing an attribute as a marker in a
single case, without some expectation that it has a future beyond
that.
> Another is precision. Stating vague goals and standards ("I want
> @implicit done well") and systematically asking others to actually put
> in the work is less desirable than providing concrete, motivated,
> actionable feedback.
As I originally said, my feedback is concrete: specify @implicit, this
DIP depends on it.
My language like "@implicit done right" came later, as a reference to
prior comments.
As I've said, I actually really want @implicit, but I want to be
satisfied by it's definition and somewhat convinced that it has a
future, and specifically, that it's NOT just a marker to be used in
this case.
It's not about 'asking others to put in the work', this DIP has a
dependency on it, so it can't not be defined. The definition is
currently "it's a marker, and maybe we might do something in the
future", and that's a poor definition.
If I presented a DIP which casually dropped in a new attribute, you
would absolutely insist that I specify it.
> To the second point: we have a history of defining features too
> permissively, to then regret not having waited to accumulate experience.
> Starting with a restricted version then building on experience with it
> seems to be a much better strategy. From that perspective, introducing
> implicit only for restricted copy construction seems like a good step
> that doesn't take others, without precluding them.
There's also @property... and 'scope' as existed prior DIP1000, and 'in'.
I think this thing needs at least a little spec-ing. If it's clear up
front that it's not going anywhere (easily shot-down or whatever),
then it's not a good choice.
If it looks generally promising for the future, and there's no obvious
roadblocks for wider deployment, then we're good, and I'll desist on
this point.
I don't know how we can be confident of that without at least a little
exploration.
> > I don't see myself getting behind introduction of @implicit on such
> > terms that it's nothing but "a marker for the copy constructor". So
> > this 'mountain' is critical to understanding whether I can support
> > this DIP as proposed or not.
>
> I'd put it a slightly different way. "Getting behind" and "supporting or
> not" suggests a position of power and an emphasis on the politics of the
> process. The natural counter to this would be asking whether your
> support is necessary, which put us all in a very unproductive position.
Presenting a proposal to the community is an implicit request for
support. I'm not saying I have any power further than my reading of
the proposal and sharing my own judgement of its merit.
You can do whatever you do... I'm just saying what I find satisfying,
and this proposal is not satisfying without some further
substantiation of the proposed new attribute.
> The right emphasis is not getting your support on a given DIP, but
> instead us all benefiting of your active contribution to a better DIP.
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'm the only one that
finds problem with that.
My feeling is inspired by '@property', 'scope', 'in'. We don't need
any more events like those.
Re: Copy Constructor DIP
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.
Re: Copy Constructor DIP
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 an obvious and intuitive complement to 'explicit' in C++? I think the name's perfect, but I need to know it works in general to find it acceptable. As a marker used in this one case, it's a terrible name, as a generalised concept, it's perfect.
Re: Copy Constructor DIP
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 existing code? > > Is it the unlikely^^2 case that the function exists somewhere and > > doesn't perform copy construction? > >1. the function is highly unlikely to exist because postblit; it's a > > meaningless function to write. are there any known instances of that > > signature in the wild? > >2. if the function does exist, it's highly unlikely that it doesn't > > perform a valid copy construction; what else could it possibly do? > >3. remaining cases are broken by this DIP, but they are probably > > crazy and deserve to be deprecated! > > > > Is there any reasonable existing use of the signature that would be > > legitimately broken by being invoked implicitly? > > I feel like there's something that I'm missing... but if there's not, > > then just change the semantic. > > > > I reason; copy construction is something so fundamental. It will be > > written by basically every programmer with relative high frequently, > > and adding awkward syntax or weird language baggage to the concept > > feels like a very poor choice. > > By contrast, if there's 1 user out there who used the copy-constructor > > signature to do some weird thing other than copy construction, and > > their code is broken by this change, his use case does not balance the > > imposition applied to every implementation of copy constructor forever > > from this time forward. > > This is so much more important than that, it's extremely fundamental > > language stuff, and needs to be as friction-less as possible, and it > > should certainly not reek of legacy drama. > > Noted. So in summary you would be okay with changing semantics of > existing code, under the intuition that the change is unlikely to be > destructive anyway. Yes, I think this is too important and fundamental to lug historical baggage along with it for the rest of time. That said, I'm firmly in favour of @implicit, but the terms of introduction here are not satisfying. If we're going to add yet another attribute, I want to know it's a really good attribute. Adding a whole new attribute just as a marker in this case, and no clear sign that it may or may not be developed into an obvious extension of the concept (and what that looks like) is not satisfactory grounds to introduce a new attribute. I don't understand your objection to this point. I feel like you of all people should be arguing this case. If the DIP specifies introduction of an attribute, then I can't see how there's not a dependency on specification of the attribute. (That doesn't necessarily mean it must be implemented all at once, but I feel like the spec/intent should be presented up-front)
Re: Copy Constructor DIP
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 specified and the copy constructor is not > suitable for assignments because it modifies immutable field `b`). > > What are your opinions on this? Right; I figure, if the struct contains members that can't be copied, then the struct is defined in such a way that it simply can't be copied. I mean, if the copy constructor can't be used to copy the thing, then is copying the struct valid at all? What would a valid copy operation on a struct with an immutable field do? Either way, in that case, a good error should inform the user they need to write an explicit opAssign.
Re: Copy Constructor DIP
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.com/search?q=%22this%5C%28ref%22+language%3AD=Code
The answer seems to be: not many. Most of the results above
are false positives because github won't let me escape the
left parenthesis.
A proposal that just works without any user intervention
would definitely be attractive.
The drawback is silent modification of code behavior.
Consider:
import std.stdio;
struct A {
this(ref immutable A obj) { writeln("x"); }
}
void main()
{
immutable A a1;
A a2 = A(a1);
A a3 = a1;
}
With the current language, "x" is printed once. If we make
the ctor implicit, "x" is printed twice.
In the "levels of hell" of semantics changes, probably the
nicest is allowing code to compile that previously didn't.
Then, refusing to compile code that previously did would be
definitely bad. But if you want to drink the cup of disgrace
to the bottom, you must reach for silent change of behavior.
I agree on the levels of hell. I wasn't aware the kind of
change above would happen - methinks it should be in the DIP.
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). Thanks.
I think I now even understand why `@implicit` is there to
begin with. I still think it's confusing, so imagine someone
new to the language.
Interesting. Coming from a C++ background makes the matter
obvious because there's plenty of implicit vs. explicit
discussion. To compensate for my bias - what do you think would
be a better attribute name?
I came to D via C++ as well. Maybe my brain short-circuited
because I saw `A a3 = a1;` in a discussion about copy
constructors and assumed it would be called, and didn't realise
it wouldn't have been before. I just took for granted the
implicitness of the constructor call, since that's what C++ does!
I wasn't even aware one could declare a C++ copy constructor
`explicit` until I tried it just now. It's just not something
I've ever thought about.
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.
Atila
Re: Copy Constructor DIP
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 usual c'tor for `B` ?
struct implicit{}
struct A {
@safe @implicit this(ref A) {}
}
struct B {
@implicit @safe this(ref B) {}
}
We'll change that part to accept the standard attribute syntax.
Re: Copy Constructor DIP
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 implicit{}
struct A {
@safe @implicit this(ref A) {}
}
struct B {
@implicit @safe this(ref B) {}
}
Re: Copy Constructor DIP
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). Thanks. [...] Interesting. Coming from a C++ background makes the matter obvious because there's plenty of implicit vs. explicit discussion. To compensate for my bias - what do you think would be a better attribute name? Andrei Why "@implicit" is an attribute and not a keyword? -Alexander
