Re: two points
On 02/09/2017 03:02 AM, Walter Bright wrote: It took me a while to find it, because you were using a pseudonym that I did not recognize. There are a number of frequent contributors to D using pseudonyms, and all have this issue with varying degrees. [...] I suppose I could write a cheat sheet and tape it to the wall of my office, but why not just use your name? Partly because I just like online handles. Also, brevity: "Sabalausky" is a bit of a monster and also tends to intimidate the crap out anyone trying to pronounce it (and very understandably so). "Abscissa" is shorter than my last name alone, easier to spell, plus I've been using it for about 20 years, so it's kind of just habit now and almost just as much a name to me online as "Nick". Not that it's much easier to pronounce (except for those well-versed in uncommonly-used math terminology), but it's probably at least a little less panic-inducing, pronunciation-wise ;) And online (in general anyway), I like that "Abscissa" is less uniquely-identifiable than my name - unlike my name, there actually ARE other people going by "Abscissa". I like having my online identity split into multiple ones, and I like the lack of clarity as to which "Abscissa" fellas are the same ones: It creates privacy in a frontier that is increasingly "privatized big brother". Reliably-unique real names like mine are a data miner's dream - may as well be going by my social security number. Unlike "Abscissa", anyone going by "Nick Sabalausky" is either me or somebody deliberately impersonating me. In any case, your point is certainly a valid one. I've adjusted my newsreader to include Abscissa along with my real name, so hopefully that will at least help.
Re: two points
On Thursday, 9 February 2017 at 20:12:06 UTC, Joseph Rushton Wakeling wrote: Out of curiosity: is it typical that it would not post until some way into the discussion (as in that example)? I could see why it would be irritating if it popped up once discussion and review had already started happening. We enabled it at this point and thus the mention-bot hasn't had a comment for this PR. This was simply the first PR I found. Assuming that the bot can be relied on to be 'first responder' to any PR Yes, It safely be relied on this fact (it uses Vibe.d). Moreover, the dlang-bot updates its comment on every new PR event. I'm happy to try to draft an alternative text for it to post (and maybe also look at what texts it can link to). Thanks a lot for pushing this! Let's move this discussion over to the dlang-bot: https://github.com/dlang-bots/dlang-bot/pull/44
Re: two points
On Thursday, 9 February 2017 at 23:44:31 UTC, Walter Bright wrote: I appreciate how frustrating it must be to have people saying, 'Hey, do this! Do that!' without necessarily volunteering their own efforts in support, but organizational improvements so very often fail unless they are eagerly pursued at a leadership level. Before I respond, just wanted to say: I hope the above didn't come over as a personal attack, it wasn't meant as one. I was speaking in general about my experience of what can best influence change. There are 29 people with commit privileges on Phobos: https://github.com/orgs/dlang/teams/team-phobos What do you suggest? What are you willing to step up and do? I'm painfully aware that I have limited ability to commit time and energy right now. I think that's one reason have been pushing this discussion: because my time is limited, when I _do_ find time to craft some code and send it to Phobos or elsewhere, it's quite precious to me, and I try to take a lot of care over it. It's not very nice to feel that this time is wasted because no one is paying attention to the results, and it's not very nice to feel that this is a situation that is just accepted. So, that said, what would I suggest? Well, 29 people with commit privileges is less than 4 currently-open PRs per person. Let's be conservative and suppose 10 of them are regularly active. What I would suggest is it takes one or two people with authority (important caveat, more on this in a moment) to periodically nudge those 10+ people about any PRs that (i) do not have an assigned reviewer with commit rights or (ii) do have an assigned reviewer but haven't had any activity in more than, say, 2 weeks. This doesn't need to be orders (impossible in a volunteer project) -- just encouraging requests for help and awareness-raising to make sure that no PR falls behind. Then in turn, the 10+ people with commit rights need to be actively encouraging appropriate people to review the PRs they are responsible for, with the sense that it strongly matters that no PR author feels they're being abandoned (a feeling which needs to be encouraged by the top people: if the people with commit rights aren't nudging the reviewers on a particular PR, they need to be nudged themselves). The authority bit matters because the one or two people at the top need to be able to field the questions that the 10+ with commit rights can't decide for themselves -- in a way that helps them understand the principles behind those decisions so that they can apply them themselves, confident that they're not going to be knocked back if the apply the same principles in future. Basically, the role of the senior authority figure here is to support the people with commit rights in learning how to make decisions which won't need to be countermanded. No one person scales, but 10 people who understand 95% of that one person's thought _can_ -- and they can pass on that understanding to others. Of course, I understand that I might be suggesting things that have been tried and have not worked out. But you asked for my suggestions, so ... that's what seems important to me.
Re: two points
On Thursday, 9 February 2017 at 17:45:15 UTC, Nick Sabalausky wrote: No. There should be appropriate checks and reviews, yes. But, no, every little fix and improvement shouldn't feel like trying to get somewhere in a year-long tabs vs spaces debate or making a big-budget sales pitch to Indecisives Anonymous. Yep! There are currently 165 poor sinners in DMD PR purgatory. The oldest is going on 5 years, waiting on someone to make a decision whether to use "-version", "-versions", "-dversion", or "-version=?". Then, it would have to be rebased, and languish again for another indeterminate amount of time. I wouldn't be at all surprised if the original contributor has moved on; I would have 4 years ago. Mike
Re: two points
On 2/9/2017 1:45 PM, Jon Degenhardt wrote: However, when a PR associated with the issue is created, the ticket itself is normally not updated until after the review is finished and the PR closed, to late to help out. It normally is. I do it for all mine and for others I notice that have not so.
Re: two points
On 2/9/2017 1:06 PM, Joseph Rushton Wakeling wrote: On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote: *Anyone* in this community can step up and do that. Anyone can make observations and proposals, but not everyone has the authority to effect change. Anyone can proactively look at, review, analyze, etc. any PR. I appreciate how frustrating it must be to have people saying, 'Hey, do this! Do that!' without necessarily volunteering their own efforts in support, but organizational improvements so very often fail unless they are eagerly pursued at a leadership level. There are 29 people with commit privileges on Phobos: https://github.com/orgs/dlang/teams/team-phobos What do you suggest? What are you willing to step up and do?
Re: two points
On Thursday, 9 February 2017 at 16:48:16 UTC, Joseph Rushton Wakeling wrote: There's clearly in part a scaling problem here (in terms of how many people are available in general, and in terms of how many people have expertise on particular parts of the library) but it also feels like a few simple things (like making sure every PR author is given a reliable contact or two who they can feel entitled to chase up) could make a big difference. Regarding the scaling problem - Perhaps the bug system could be used to help engage a wider community of reviewers. Specifically, update the bugzilla ticket early in the PR lifecycle as an alerting mechanism. This idea comes from my experiences so far. I've found any number of bugs and enhancements in the bug system that directly interact with things I'm implementing. I typically add myself to CC list so I hear about changes. In many of these cases I'd be willing to help with reviewing. However, when a PR associated with the issue is created, the ticket itself is normally not updated until after the review is finished and the PR closed, to late to help out. Of course, someone like myself, a part-timer to the community at best, should not be a primary reviewer. However, for specific issues, it's often the case that I've studied the area of code involved. If there is a wider set of people in a similar situation perhaps this might help engage a wider set of people. --Jon
Re: two points
On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote: *Anyone* in this community can step up and do that. Anyone can make observations and proposals, but not everyone has the authority to effect change. I appreciate how frustrating it must be to have people saying, 'Hey, do this! Do that!' without necessarily volunteering their own efforts in support, but organizational improvements so very often fail unless they are eagerly pursued at a leadership level.
Re: two points
On Thursday, 9 February 2017 at 16:48:16 UTC, Joseph Rushton Wakeling wrote: which is that after some initial interest and feedback, the PR just got left alone with no decision to accept or reject it, and no indication of why. This is why I only contribute to Phobos to be quite honest. I count ten active reviewers with pull rights on Phobos. The other repos, tools: one dmd: three druntime: three dlang.org: two
Re: two points
Dne 9.2.2017 v 21:43 Walter Bright via Digitalmars-d-announce napsal(a): On 2/9/2017 12:29 PM, Joseph Rushton Wakeling wrote: Yes, but it could be good to examine what can be done to more pro-actively look at open PRs that have had no recent follow-up. *Anyone* in this community can step up and do that. This obviously does not work :(
Re: two points
On 2/9/2017 12:29 PM, Joseph Rushton Wakeling wrote: Yes, but it could be good to examine what can be done to more pro-actively look at open PRs that have had no recent follow-up. *Anyone* in this community can step up and do that.
Re: two points
On Thursday, 9 February 2017 at 19:53:37 UTC, Walter Bright wrote: There's a lot going on needing attention, and sometimes a bit of championing is needed by their proponents. Yes, but it could be good to examine what can be done to more pro-actively look at open PRs that have had no recent follow-up. It's not really going to work that well if attention gets given substantially on the basis of who's most eagerly seeking it. People like that metaphor "It's the squeaky wheel that gets the grease", but as a first aid trainer once pointed out to me, the quieter patient may be the one more in need of immediate attention. Also, please keep in mind that the smaller and more focussed a PR is, the more likely it'll have a quick resolution. Unfortunately my current one is large with good reason. But I think you'll find I also provided very detailed commit messages to explain and justify all my changes ;-)
Re: two points
On Thursday, 9 February 2017 at 19:58:57 UTC, Seb wrote: We gave this a try a couple of months ago with Facebook's mention-bot: Example: https://github.com/dlang/phobos/pull/4318#issuecomment-241817191 Repo: https://github.com/dlang-bots/mention-bot Eventually I disabled it because people complained about the added noise. It's great that you gave this a go. Seriously, people considered one small informative post in the PR to be "added noise"? :-( Out of curiosity: is it typical that it would not post until some way into the discussion (as in that example)? I could see why it would be irritating if it popped up once discussion and review had already started happening. Assuming that the bot can be relied on to be 'first responder' to any PR, I'm happy to try to draft an alternative text for it to post (and maybe also look at what texts it can link to).
Re: two points
On Thursday, 9 February 2017 at 19:42:03 UTC, Jack Stouffer wrote: On Thursday, 9 February 2017 at 19:36:52 UTC, Walter Bright wrote: Good idea! Please investigate how to get github to generate such emails. In the meantime, the PR guidelines are here: We gave this a try a couple of months ago with Facebook's mention-bot: Example: https://github.com/dlang/phobos/pull/4318#issuecomment-241817191 Repo: https://github.com/dlang-bots/mention-bot Eventually I disabled it because people complained about the added noise. This is already somewhat done with the PR bot we have. The DlangBot notifies reviewers on the DMD repo, but not Phobos for some reason. All it does on Phobos is auto close bugzilla issues when a bug fix PR is pulled into master. It does a bit more (e.g. since a couple of weeks it can also automatically merge PR once all CI status checks pass) I say enable the bot for Phobos. It would be a small task to also have the bot post the PR guidelines. As mentioned above, the bot is already enabled and it receives all interesting hook events from Phobos, see e.g.: https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/app.d#L124 I think Martin is the maintainer of the bot. You can find the code here: https://github.com/dlang-bots/dlang-bot
Re: two points
On 2/9/2017 8:55 AM, Joseph Rushton Wakeling wrote: On Thursday, 9 February 2017 at 09:49:53 UTC, Walter Bright wrote: In any case, shouldn't it be an uphill battle to merge things? There are a lot of things that need to be satisfied to merge something. Being too hasty leads to legacy code that we come to regret, angry people whose code was broken, and technical debt. There's a difference between it being an uphill battle because review and feedback are careful, cautious, in-depth and strict (as they should be!), versus it being an uphill battle because no feedback or interest is being offered and PRs are left to bitrot. :-( That certainly does happen, but it isn't quite the case with Nick's PRs. I accept that there are a lot of things that need to be satisfied to merge something. Personally speaking, I'm willing to endure any number of rebases and conflict-fixes, so long as I'm getting feedback and engagement that allows my PR to become better code. It's when I'm _not_ getting any indicators as to what needs to be satisfied that things become problematic. There's a lot going on needing attention, and sometimes a bit of championing is needed by their proponents. Also, please keep in mind that the smaller and more focussed a PR is, the more likely it'll have a quick resolution.
Re: two points
On Thursday, 9 February 2017 at 19:36:52 UTC, Walter Bright wrote: Good idea! Please investigate how to get github to generate such emails. In the meantime, the PR guidelines are here: This is already somewhat done with the PR bot we have. The DlangBot notifies reviewers on the DMD repo, but not Phobos for some reason. All it does on Phobos is auto close bugzilla issues when a bug fix PR is pulled into master. I say enable the bot for Phobos. It would be a small task to also have the bot post the PR guidelines. I think Martin is the maintainer of the bot.
Re: two points
On 2/9/2017 8:48 AM, Joseph Rushton Wakeling wrote: Contrast this with the experience I had the one time I submitted a (tiny, trivial) patch to rust: immediately after submitting the PR I got a message from their 'highfive' robot that included: * a friendly thank you for the PR; * the GitHub ID of a contact who I could expect to be taking responsibility for the PR, who was also assigned as a reviewer; * some helpful notes on how to add changes to the PR if requested; * a link to the contributor guidelines. By contrast with a Phobos PR it's not clear who to contact if review or decision-making is not forthcoming. Good idea! Please investigate how to get github to generate such emails. In the meantime, the PR guidelines are here: http://wiki.dlang.org/Starting_as_a_Contributor#Create_a_pull_request The teams can be found here: https://github.com/orgs/dlang/teams Please help improve the guidelines.
Re: two points
On 02/09/2017 04:49 AM, Walter Bright wrote: On 2/8/2017 11:09 PM, Nick Sabalausky wrote: And any PRs I have managed to get through were all uphill battles the whole way. You have contributed 5 PRs to dmd: https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa 1 is open (it's controversial) 1 closed (today by me) Well, I suppose I brought that one on myself by complaining about it being ignored :/ 3 merged 1 in 6 days 2 in 1 day Overall, I think you've done well. Note that those quickly merged ones were several years ago, back before the battles to get anything accepted reached ridiculous levels. In any case, shouldn't it be an uphill battle to merge things? No. There should be appropriate checks and reviews, yes. But, no, every little fix and improvement shouldn't feel like trying to get somewhere in a year-long tabs vs spaces debate or making a big-budget sales pitch to Indecisives Anonymous.
Re: two points
On Thursday, 9 February 2017 at 09:49:53 UTC, Walter Bright wrote: In any case, shouldn't it be an uphill battle to merge things? There are a lot of things that need to be satisfied to merge something. Being too hasty leads to legacy code that we come to regret, angry people whose code was broken, and technical debt. There's a difference between it being an uphill battle because review and feedback are careful, cautious, in-depth and strict (as they should be!), versus it being an uphill battle because no feedback or interest is being offered and PRs are left to bitrot. :-( I accept that there are a lot of things that need to be satisfied to merge something. Personally speaking, I'm willing to endure any number of rebases and conflict-fixes, so long as I'm getting feedback and engagement that allows my PR to become better code. It's when I'm _not_ getting any indicators as to what needs to be satisfied that things become problematic.
Re: two points
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote: The PR in question: https://github.com/dlang/dmd/pull/4745 It took me a while to find it, because you were using a pseudonym that I did not recognize. There are a number of frequent contributors to D using pseudonyms, and all have this issue with varying degrees. This is a fair point in its own right, but it's completely orthogonal to the issue Nick is complaining about -- which is that after some initial interest and feedback, the PR just got left alone with no decision to accept or reject it, and no indication of why. That's really a very unpleasant situation to face, regardless of whether the contributor in question is a well-known name or some complete anonymous stranger. I have a PR of my own that's been in this situation for (only!) a month now, and it's distinctly frustrating, particularly because it was a contribution that Andrei specifically called for on these forums: https://github.com/dlang/phobos/pull/5011 (... Andrei's request: https://forum.dlang.org/post/o1cqdb$245o$1...@digitalmars.com) Contrast this with the experience I had the one time I submitted a (tiny, trivial) patch to rust: immediately after submitting the PR I got a message from their 'highfive' robot that included: * a friendly thank you for the PR; * the GitHub ID of a contact who I could expect to be taking responsibility for the PR, who was also assigned as a reviewer; * some helpful notes on how to add changes to the PR if requested; * a link to the contributor guidelines. By contrast with a Phobos PR it's not clear who to contact if review or decision-making is not forthcoming. There's clearly in part a scaling problem here (in terms of how many people are available in general, and in terms of how many people have expertise on particular parts of the library) but it also feels like a few simple things (like making sure every PR author is given a reliable contact or two who they can feel entitled to chase up) could make a big difference.
Re: two points
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote: I suppose I could write a cheat sheet and tape it to the wall of my office, but why not just use your name? It shouldn't matter who wrote it. Review the code, not the author, especially on small ones like this which new contributors might be using to test the waters.
Re: two points
On 2/8/2017 11:09 PM, Nick Sabalausky wrote: And any PRs I have managed to get through were all uphill battles the whole way. You have contributed 5 PRs to dmd: https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa 1 is open (it's controversial) 1 closed (today by me) 3 merged 1 in 6 days 2 in 1 day Overall, I think you've done well. https://github.com/dlang/druntime/pulls?q=is%3Apr+author%3Aabscissa 5 PRs, 3 merged. https://github.com/dlang/phobos/pulls?q=is%3Apr+author%3Aabscissa 14 PRs, 1 merged. (I didn't check all the reviews, but the ones I did looked fair.) --- In any case, shouldn't it be an uphill battle to merge things? There are a lot of things that need to be satisfied to merge something. Being too hasty leads to legacy code that we come to regret, angry people whose code was broken, and technical debt. Check out our current list of regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regression_status=NEW_status=ASSIGNED_status=REOPENED_id=213638_format=advanced Hasty merges wind up there, and usually someone other than the one who broke it has to fix it.
Re: two points
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote: I do not understand using pseudonyms on github. It can hardly be a privacy issue, as github doesn't hide your name. But it definitely impedes your "brand", i.e. your reputation, as it becomes divided in two. Github does not provide a "reverse phone book" where I can search for a PR under your name, nor does it provide any sort of cross reference. Searching (via github) the dmd repository for your name turns up nothing. One of the reasons could be simply because one is known under a nickname on a bunch of other resources where he posts to, and that now working for the reputation too - because posting something with other name could get you banned or just people looking with suspicious for any code and links posted. Now, since we on D forum and that "other" world reputation doesn't matter here or any other reasons, some will prefer just using "real" name. Some people also avoid using their work-associated emails with personal/fan projects. Because of same thing with reputation/proffesionalism/etc., (unnecesary questions from employer too? just a guess, whatever) And more, and more... Things are complicated.
Re: two points
On 2/8/2017 11:09 PM, Nick Sabalausky wrote: I fixed an issue where "///"-style doc comments resulted in excessive paragraph breaks...must've been over a year ago. Simple fix for a nagging bug. The fix worked. Caused no problems. No controversy. And to this day, just went completely ignored despite my periodic nagging about it. Eventually got tired wasting my time babysitting the constant need for rebasing and manual merge fixes just for something that proved guaranteed to be ignored. And any PRs I have managed to get through were all uphill battles the whole way. The PR in question: https://github.com/dlang/dmd/pull/4745 It took me a while to find it, because you were using a pseudonym that I did not recognize. There are a number of frequent contributors to D using pseudonyms, and all have this issue with varying degrees. I do not understand using pseudonyms on github. It can hardly be a privacy issue, as github doesn't hide your name. But it definitely impedes your "brand", i.e. your reputation, as it becomes divided in two. Github does not provide a "reverse phone book" where I can search for a PR under your name, nor does it provide any sort of cross reference. Searching (via github) the dmd repository for your name turns up nothing. I found it by searching the notification emails I get from github, which ironically are sent using your name rather than Abscissa (further confusing matters). I suppose I could write a cheat sheet and tape it to the wall of my office, but why not just use your name?
Re: two points
On 02/09/2017 01:08 AM, Joakim wrote: I agree that "coercion," or more accurately the tyranny of the default, is the dominant factor in language popularity even today, but you're reaching when you apply that to web frameworks too. Fair enough. It was just another example trying to make the point that "if you want to do X, then you have little choice but use Y" is, as you say, the dominant factor in language popularity. I can grant that the web framework examples are weaker examples. D's problem on the client is that the popular platforms are still very much tied to certain favored languages: iOS - ObjC and Swift Android non-game apps - Java Android games - C/C++ Windows - C# or C++ Web - Javascript Three of the four major client platforms all allow other languages (with the fourth starting to with WebAssembly), but you're often fighting the tide if you choose a non-default language so most don't bother. That's a good way of explaining it, I like that. We can make the dev experience more pleasant on those platforms, as I believe has happened now that we support the MS toolchain on Windows, but D is unlikely to become popular without a killer app that demonstrates its suitability. That's not coercion, but something we can actually control. I hope you're right, but I worry that even "killer app example" may not be enough, and that the lack of one may turn out to be just another red herring excuse for "why aren't using D". After all, I think vibe's approach to server development comes very close to "killer app" yet, far as I've seen, it doesn't appear to have proven a major win for D so far. Then again, having D in the "my secret weapon" category has certain benefits, too, so I guess I can't be TOO sour ;) On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote: I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory. So, I would not recommend it as a project for anyone until the D leadership decides to get involved. I think this misunderstands how open source works: the whole point is that you don't need anybody's permission to go do this. Walter and Andrei, or any other OSS core team, are much more likely to approve something if you have an implementation that works well. Look at Ilya and what happened after he showed them Mir. You're right, in theory. But Mike is unfortunately very right about the whole "suffer an eternity in pull request purgatory." I fixed an issue where "///"-style doc comments resulted in excessive paragraph breaks...must've been over a year ago. Simple fix for a nagging bug. The fix worked. Caused no problems. No controversy. And to this day, just went completely ignored despite my periodic nagging about it. Eventually got tired wasting my time babysitting the constant need for rebasing and manual merge fixes just for something that proved guaranteed to be ignored. And any PRs I have managed to get through were all uphill battles the whole way. We have far too high a threshold for letting things actually happen. It didn't used to be that way, and that was a key reason why D became as good as it's gotten in the first place. So I'm not surprised people familiar with D go to lengths to avoid putting the effort into PRs that are much more major than my comparatively trivial PRs: It's proven to come with a depressingly high likelihood of turning out to be a complete waste of time. At the risk of sounding hyperbolic, I think this is D's next biggest problem after the lack of any "If you want to do X, your only real choice is D". Though I admit I might be a little biased on this particular point though.
two points
I'm not going to fill out the questionnaire because I'm not at a company and have not tried Mir, but two points about what Nick and Mike wrote. On Wednesday, 8 February 2017 at 20:40:48 UTC, Nick Sabalausky wrote: Coercion (and perceived coercion[1] for that matter) makes technologies popular far more than any other factor. The computing sector is NOT a meritocracy, not by a longshot. That right there is D's #1 biggest marketing flaw, period. If you nail that coercion part, it doesn't matter HOW badly you do on any other technical or marketing aspect. Been proven time and time again. And if you DON'T have that coercion, you face an uphill battle no matter how good you do on technical and marketing fronts. Also been proven time and time again. I agree that "coercion," or more accurately the tyranny of the default, is the dominant factor in language popularity even today, but you're reaching when you apply that to web frameworks too. As you admit, rails didn't become as big as it might have because there were quickly many other web frameworks, ie languages and frameworks on the server are very competitive and that market is very fragmented, though PHP is likely the biggest. D's problem on the client is that the popular platforms are still very much tied to certain favored languages: iOS - ObjC and Swift Android non-game apps - Java Android games - C/C++ Windows - C# or C++ Web - Javascript Three of the four major client platforms all allow other languages (with the fourth starting to with WebAssembly), but you're often fighting the tide if you choose a non-default language so most don't bother. We can make the dev experience more pleasant on those platforms, as I believe has happened now that we support the MS toolchain on Windows, but D is unlikely to become popular without a killer app that demonstrates its suitability. That's not coercion, but something we can actually control. On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote: I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory. So, I would not recommend it as a project for anyone until the D leadership decides to get involved. I think this misunderstands how open source works: the whole point is that you don't need anybody's permission to go do this. Walter and Andrei, or any other OSS core team, are much more likely to approve something if you have an implementation that works well. Look at Ilya and what happened after he showed them Mir. Now, you may not want to go do this on your own if you believe it's a lot of effort, could use a design the core team may not approve, and don't want to maintain or develop your own fork indefinitely, but that's a lot of "if"s. I doubt it would be a lot of effort to strip D down like this, but I have not looked into it.
