Re: A facebook group for D programmers
On Monday, 17 September 2018 at 18:40:21 UTC, Bill Baxter wrote: Here's the link : https://www.facebook.com/dlang.org . ;-) That's the page, not the group. It seems the group is set to secret, it'll make joining very hard, only through invitations.
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.
Discord RPC D - rich presence for your games
Hello everybody, Today I've released "Discord RPC D" - a static binding to, guess what, "Discord RPC". It's the successor of my previous Derelict one which unfortunately didn't work as expected. # Discord, should I know this thing? Discord is modern popular text+voice chat client (some see it as replacement for Teamspeak and Skype). There's also a D community server that has been mentioned here before[0]. # So, what's this "Rich Presence"[1] about? Well, it's the way of integrating your game/app into Discord. It allows to display your game/app's title and a few stats about a player's current session on the their status box in Discord. Beyond an image (you can upload multiple ones and choose which one to display from your game, so different levels in your game can feature different ones) plus an icon, Rich Presence allows to show timers. This all is more or less free promotion for your game and can be incentive for others. Moreover, it brings to opportunity to extend multiplayer game-matching mechanisms - players can invite other users to multiplayer parties and those can join such session with just a click in Discord. For more details you might want to checkout the Rich Presence page[1]. # To my package It's on DUB[2] and should be straight-forward to use. It's compatible with Discord RPC v3.3.0, as the version tag of the package suggests. The Discord RPC library is open source and licensed under terms of the MIT license. # Usage Checkout the bundled "send-presence" example[3]. Please note that it's a D port of the original C example. Thanks for reading :) - Elias [0] https://forum.dlang.org/post/xstmkudtcpogxhvce...@forum.dlang.org [1] https://discordapp.com/rich-presence [2] https://code.dlang.org/packages/discord-rpc [3] https://github.com/voidblaster/discord-rpc-d/blob/master/examples/send-presence/send_presence.d
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: A facebook group for D programmers
Here's the link : https://www.facebook.com/dlang.org . ;-) On Sun, Sep 16, 2018 at 11:31 PM Russel Winder via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > And there is a Facebook group D Programming Language already. > > On Sun, 2018-09-16 at 16:36 -0700, Steven Schveighoffer via > Digitalmars-d-announce wrote: > > On 9/16/18 2:51 PM, Peter Alexander wrote: > > > On Sunday, 16 September 2018 at 20:19:32 UTC, Murilo wrote: > > > > Hello everyone, I was so amazed with the D language that I > > > > created a > > > > facebook group for us all to be connected and share information. > > > > It is > > > > called "Programming in D", it has already 55 members. Please join > > > > the > > > > group and invite everyone else to join it. That way we can show > > > > the > > > > world how amazing the D language is. > > > > > > Probably would be a good idea to link to the group. I couldn't find > > > it > > > with search. > > > > This seems pretty... spamish. > > > > Apologies if that's not true, but the original message is so > > fill-in-the-blank-with-target-topic that it's hard to take > > seriously. > > Also the "Already has 55 members" seems weird too. Especially if > > it's > > never been announced before. > > > > -Steve > -- > Russel. > === > Dr Russel Winder t: +44 20 7585 2200 > 41 Buckmaster Roadm: +44 7770 465 077 > London SW11 1EN, UK w: www.russel.org.uk > >
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: A facebook group for D programmers
And there is a Facebook group D Programming Language already. On Sun, 2018-09-16 at 16:36 -0700, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 9/16/18 2:51 PM, Peter Alexander wrote: > > On Sunday, 16 September 2018 at 20:19:32 UTC, Murilo wrote: > > > Hello everyone, I was so amazed with the D language that I > > > created a > > > facebook group for us all to be connected and share information. > > > It is > > > called "Programming in D", it has already 55 members. Please join > > > the > > > group and invite everyone else to join it. That way we can show > > > the > > > world how amazing the D language is. > > > > Probably would be a good idea to link to the group. I couldn't find > > it > > with search. > > This seems pretty... spamish. > > Apologies if that's not true, but the original message is so > fill-in-the-blank-with-target-topic that it's hard to take > seriously. > Also the "Already has 55 members" seems weird too. Especially if > it's > never been announced before. > > -Steve -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
