www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Clojure and Pull Request Controversy

reply Walter Bright <newshound2 digitalmars.com> writes:
The issue of prioritization of reviewing PRs, etc, perennially comes up and has 
done so again recently:

https://digitalmars.com/d/archives/digitalmars/D/It_is_the_year_2020_why_should_I_use_learn_D_321380.html#N321572

It seems we're not the only group struggling with this issue. Food for thought, 
and some controversy:

https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

https://gist.github.com/halgari/c17f378718cbd2fd82324002133ef678#gistcomment-2768338

https://news.ycombinator.com/item?id=18538123
Nov 27 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 28 November 2018 at 00:12:15 UTC, Walter Bright 
wrote:

 The issue of prioritization of reviewing PRs, etc, perennially 
 comes up and has done so again recently:

 https://digitalmars.com/d/archives/digitalmars/D/It_is_the_year_2020_why_should_I_use_learn_D_321380.html#N321572

 It seems we're not the only group struggling with this issue. 
 Food for thought, and some controversy:

 https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

 https://gist.github.com/halgari/c17f378718cbd2fd82324002133ef678#gistcomment-2768338

 https://news.ycombinator.com/item?id=18538123


The good news about this is that the D foundation has recently 
hired a PR manager, and he is doing good work! Old pull request 
has been resurrected and merge, because of this!
(Thanks Nicholas Wilson!)
Nov 27 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 28, 2018 at 12:22:27AM +0000, 12345swordy via Digitalmars-d wrote:
[...]

 The good news about this is that the D foundation has recently hired a
 PR manager, and he is doing good work! Old pull request has been
 resurrected and merge, because of this!  (Thanks Nicholas Wilson!)


Ahh, so *that's* what happened!  I was glancing at the Phobos git log
earlier today and noticed Nicholas kept showing up.  Now I know why.
I'd also like to say, thanks, Nicholas Wilson!  Keeping the PR queue
down to size can be a tedious and thankless job sometimes (speaking from
personal experience), so kudos for the much needed work!


T

-- 
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and intoxicate. It
is the old things that are young. -- G.K. Chesterton
Nov 27 2018
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 28 November 2018 at 00:36:09 UTC, H. S. Teoh wrote:

 On Wed, Nov 28, 2018 at 12:22:27AM +0000, 12345swordy via 
 Digitalmars-d wrote: [...]

 The good news about this is that the D foundation has recently 
 hired a PR manager, and he is doing good work! Old pull 
 request has been resurrected and merge, because of this!  
 (Thanks Nicholas Wilson!)


 Ahh, so *that's* what happened!  I was glancing at the Phobos 
 git log earlier today and noticed Nicholas kept showing up.


Thats probably because the buildkite style checker has been red 
for a while,
the dlang bot merges most of the dmd and druntime ones.


 Now I know why. I'd also like to say, thanks, Nicholas Wilson!  
 Keeping the PR queue down to size can be a tedious and 
 thankless job sometimes (speaking from personal experience), so 
 kudos for the much needed work!


NP. Any help resurrecting PRs is appreciated.
Nov 27 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, November 27, 2018 5:36:09 PM MST H. S. Teoh via Digitalmars-d 
wrote:

 On Wed, Nov 28, 2018 at 12:22:27AM +0000, 12345swordy via Digitalmars-d
 wrote: [...]


 The good news about this is that the D foundation has recently hired a
 PR manager, and he is doing good work! Old pull request has been
 resurrected and merge, because of this!  (Thanks Nicholas Wilson!)


 Ahh, so *that's* what happened!  I was glancing at the Phobos git log
 earlier today and noticed Nicholas kept showing up.  Now I know why.
 I'd also like to say, thanks, Nicholas Wilson!  Keeping the PR queue
 down to size can be a tedious and thankless job sometimes (speaking from
 personal experience), so kudos for the much needed work!


There was a post about it in D.Announce a couple of weeks ago:

https://forum.dlang.org/thread/swsfgggaawgylauuzjlm forum.dlang.org

- Jonathan M Davis
Nov 27 2018
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
And there is
https://forum.dlang.org/post/dsceeupaxahiwldladox forum.dlang.org too

On Wed, Nov 28, 2018 at 2:02 AM Jonathan M Davis via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Tuesday, November 27, 2018 5:36:09 PM MST H. S. Teoh via Digitalmars-d
 wrote:

 On Wed, Nov 28, 2018 at 12:22:27AM +0000, 12345swordy via Digitalmars-d
 wrote: [...]


 The good news about this is that the D foundation has recently hired a
 PR manager, and he is doing good work! Old pull request has been
 resurrected and merge, because of this!  (Thanks Nicholas Wilson!)


 Ahh, so *that's* what happened!  I was glancing at the Phobos git log
 earlier today and noticed Nicholas kept showing up.  Now I know why.
 I'd also like to say, thanks, Nicholas Wilson!  Keeping the PR queue
 down to size can be a tedious and thankless job sometimes (speaking from
 personal experience), so kudos for the much needed work!


 There was a post about it in D.Announce a couple of weeks ago:

 https://forum.dlang.org/thread/swsfgggaawgylauuzjlm forum.dlang.org

 - Jonathan M Davis
Nov 27 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Nov 27, 2018 at 06:02:17PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]

 There was a post about it in D.Announce a couple of weeks ago:
 
 https://forum.dlang.org/thread/swsfgggaawgylauuzjlm forum.dlang.org


[...]

Ah, I haven't been keeping up with my D newsgroup subscriptions. Too
much to read, too little time.  Thanks to threaded mail readers, I
delete most threads because I simply don't have enough time to read
everything. But that also means sometimes I miss important news. :-(


T

-- 
Why ask rhetorical questions? -- JC
Nov 28 2018
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 28 November 2018 at 00:12:15 UTC, Walter Bright 
wrote:

 The issue of prioritization of reviewing PRs, etc, perennially 
 comes up and has done so again recently:

 https://digitalmars.com/d/archives/digitalmars/D/It_is_the_year_2020_why_should_I_use_learn_D_321380.html#N321572

 It seems we're not the only group struggling with this issue. 
 Food for thought, and some controversy:

 https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9


I sincerely hope you don't identify with the OP.


 https://gist.github.com/halgari/c17f378718cbd2fd82324002133ef678#gistcomment-2768338

 https://news.ycombinator.com/item?id=18538123


I'm quoting the comments, because the links under "Copy link" 
didn't work.

"[...] Yes, of course everything you said is technically correct. 
You don't owe anyone anything. But you don't have to be so 
petulant about it. Saying that users aren't even entitled to an 
explanation of why they're not entitled to support is childish in 
the extreme, particularly because your own company and livelihood 
are heavily dependent upon the work that some of those users gave 
you for free.
[...]
I do appreciate that you're making your position very clear - 
hopefully this can help projects and companies make 
better-informed decisions about whether they want to be locked in 
to a project that operates this way. Just dial it back a bit, eh?"
-- briangordon

"Open source may be a gift, but it doesn't come with batteries 
included, and so there's a cost for adopting such a "gift." If 
you want people to use your software, closed- or open-source, you 
do need to make it worth their time and show some basic decency 
to your users."
-- tommyettinger

You cannot say "We need help, we're a small community!" and then 
when people step up and do help say "Who are you anyway? You're 
not entitled to anything!"

And as regards adopting the software, when you read this thread

https://forum.dlang.org/post/ljrm0d$28vf$1 digitalmars.com

you will not even think twice about whether or not to adopt it, 
you just run away. Ironically enough, it was about the time the 
post about "more radical ideas" was posted that I was beginning 
to feel very uneasy with D.

Yesterday I was innocently thinking if and how LDC+Android could 
be integrated into Android Studio via CMake etc., but then it 
occurred to me that even if I / we succeeded in doing so, the D 
code itself might still break anytime, because of "more radical 
ideas". Maybe D should be rebranded as "Minefield".
Nov 28 2018
next sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 28 November 2018 at 11:29:58 UTC, Chris wrote:

 On Wednesday, 28 November 2018 at 00:12:15 UTC, Walter Bright



 And as regards adopting the software, when you read this thread

 https://forum.dlang.org/post/ljrm0d$28vf$1 digitalmars.com

 you will not even think twice about whether or not to adopt it, 
 you just run away. Ironically enough, it was about the time the 
 post about "more radical ideas" was posted that I was beginning 
 to feel very uneasy with D.

 Yesterday I was innocently thinking if and how LDC+Android 
 could be integrated into Android Studio via CMake etc., but 
 then it occurred to me that even if I / we succeeded in doing 
 so, the D code itself might still break anytime, because of 
 "more radical ideas". Maybe D should be rebranded as 
 "Minefield".


Recte: I read the date wrong. It was years after the thread by 
Andrei that I started to feel uneasy. Mea culpa. I should have 
copped it earlier, given that said thread is from 2014!
Nov 28 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, November 28, 2018 7:48:27 AM MST Jim Balter via Digitalmars-d 
wrote:

 Rich Hickey's piece was addressed to entitled assholes and
 trolls. It's no wonder that a maggot like you responded to it as
 you did.


Let's please try to be civil. I don't agree with much of what he's said in
recent threads either, but insults don't help. They're obviously not nice,
and in general, they tend to just lead to more angry posts (from both sides)
that waste everyone's time.

- Jonathan M Davis
Nov 28 2018
parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 28 November 2018 at 17:05:57 UTC, Jonathan M Davis 
wrote:

 On Wednesday, November 28, 2018 7:48:27 AM MST Jim Balter via 
 Digitalmars-d wrote:

 Rich Hickey's piece was addressed to entitled assholes and 
 trolls. It's no wonder that a maggot like you responded to it 
 as you did.


 Let's please try to be civil. I don't agree with much of what 
 he's said in recent threads either, but insults don't help. 
 They're obviously not nice, and in general, they tend to just 
 lead to more angry posts (from both sides) that waste 
 everyone's time.

 - Jonathan M Davis


Can moderators "delete" certain post or am I blind?
Nov 28 2018
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 28 November 2018 at 20:21:04 UTC, welkam wrote:

 On Wednesday, 28 November 2018 at 17:05:57 UTC, Jonathan M 
 Davis wrote:

 On Wednesday, November 28, 2018 7:48:27 AM MST Jim Balter via 
 Digitalmars-d wrote:

 Rich Hickey's piece was addressed to entitled assholes and 
 trolls. It's no wonder that a maggot like you responded to it 
 as you did.


 Let's please try to be civil. I don't agree with much of what 
 he's said in recent threads either, but insults don't help. 
 They're obviously not nice, and in general, they tend to just 
 lead to more angry posts (from both sides) that waste 
 everyone's time.

 - Jonathan M Davis


 Can moderators "delete" certain post or am I blind?


Apparently. I had read that response and saw then that it was 
gone. The D forum page had an empty column where there is 
normally the link to the last unread entry.
Nov 28 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 28, 2018 at 08:35:33PM +0000, Patrick Schluter via Digitalmars-d
wrote:

 On Wednesday, 28 November 2018 at 20:21:04 UTC, welkam wrote:


[...]

 Can moderators "delete" certain post or am I blind?


 
 Apparently. I had read that response and saw then that it was gone.
 The D forum page had an empty column where there is normally the link
 to the last unread entry.


Deleting posts off the NNTP server does not delete it for people who
have already received them, though. E.g., through the mailing list
interface.  But at least it won't show up for "future" readers.


T

-- 
Being forced to write comments actually improves code, because it is
easier to fix a crock than to explain it. -- G. Steele
Nov 28 2018
parent bauss <jj_1337 live.dk> writes:
On Wednesday, 28 November 2018 at 20:54:40 UTC, H. S. Teoh wrote:

 On Wed, Nov 28, 2018 at 08:35:33PM +0000, Patrick Schluter via 
 Digitalmars-d wrote:

 On Wednesday, 28 November 2018 at 20:21:04 UTC, welkam wrote:


 [...]

 Can moderators "delete" certain post or am I blind?


 
 Apparently. I had read that response and saw then that it was 
 gone. The D forum page had an empty column where there is 
 normally the link to the last unread entry.


 Deleting posts off the NNTP server does not delete it for 
 people who have already received them, though. E.g., through 
 the mailing list interface.  But at least it won't show up for 
 "future" readers.


 T


Or people using the web interfaces.
Nov 28 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2018 3:29 AM, Chris wrote:

 I sincerely hope you don't identify with the OP.


I did say it was controversial.



 Yesterday I was innocently thinking if and how LDC+Android could be integrated 
 into Android Studio via CMake etc., but then it occurred to me that even if I
/ 
 we succeeded in doing so, the D code itself might still break anytime, because 
 of "more radical ideas". Maybe D should be rebranded as "Minefield".


There is a disconnect with not wanting radical new ideas, and wanting
autodecode 
removed (which will result in silent breakage).
Nov 28 2018
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 29 November 2018 at 06:17:11 UTC, Walter Bright 
wrote:

 On 11/28/2018 3:29 AM, Chris wrote:

 I sincerely hope you don't identify with the OP.


 I did say it was controversial.


Funnily enough because they are too conservative, whereas D might 
have her refers to as "feature bloat". I'd call it overstretching.


 Yesterday I was innocently thinking if and how LDC+Android 
 could be integrated into Android Studio via CMake etc., but 
 then it occurred to me that even if I / we succeeded in doing 
 so, the D code itself might still break anytime, because of 
 "more radical ideas". Maybe D should be rebranded as 
 "Minefield".


 There is a disconnect with not wanting radical new ideas, and 
 wanting autodecode removed (which will result in silent 
 breakage).


You do realize that autodecode is an old flaw that has to go 
sooner or later. It negatively affects string handling 
performance, is not even correct and is a deal breaker in a world 
where string handling is omnipresent. So removing autodecode 
would benefit the language and the users in the long run and is 
both necessary and welcome. It's not a "new idea" you might want 
to try, it is strictly necessary, just like fixing the brakes of 
your car is not a "radical new idea", but necessary. And 
reasonable paths to fix it have been proposed.

However, coming up with "radical new ideas" about memory 
management and the like and making it a feature of the language 
that breaks valid existing code only to see what happens, is a 
baaaad idea. I'd suggest something like the "D labs" for it where 
you can test all those great new ideas and features for a minimum 
of one year. What if a feature turns out to be sh*it? What if you 
realize that partial constructors sound great, but you cannot 
have partial deconstructors? D should have a "laboratory branch" 
for this but not use users as guinea pigs.
Nov 29 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2018 2:14 AM, Chris wrote:

 You do realize that autodecode is an old flaw that has to go sooner or later.


I'd remove autodecode tomorrow if I could wave the magic wand. The problem, 
though, as I point out to you again, is removing it will silently break a great 
deal of code.

You cannot have it be a deal-breaker both ways.

I'll also emphasize that you can avoid autodecode in your own projects by using 
.byChar. You are not forced to suffer its depredations in your own code.
Nov 29 2018
parent Jon Degenhardt <jond noreply.com> writes:
On Thursday, 29 November 2018 at 11:11:19 UTC, Walter Bright 
wrote:

 I'd remove autodecode tomorrow if I could wave the magic wand. 
 The problem, though, as I point out to you again, is removing 
 it will silently break a great deal of code.

 You cannot have it be a deal-breaker both ways.

 I'll also emphasize that you can avoid autodecode in your own 
 projects by using .byChar. You are not forced to suffer its 
 depredations in your own code.


A number of people in the D community have made the argument to 
me that autodecoding difficulties have been largely mitigated by 
the availability of byChar and byCodeUnit.

My assessment is different. These are valuable primitives. I 
think they suffice if developing small applications, or 
applications which need high performance string handling only in 
limited parts of the code. But I don't think they are sufficient 
if building larger applications that generally need high 
performance string handling throughout.

Part my viewpoint is from the perspective of development in team 
environments. Litmus test questions are things like "how much 
time will be spent in code review checking if autodecoding has 
been engaged/avoided correctly?"

A specific issue with the byChar/byCodeUnit approach is that the 
disabling of autodecoding gets dropped in common cases, for 
example, materializing the range as an array. (An aside, but I 
have wondered if having a character array type that 
obeyed/preserved the no-autodecode property would be a material 
help.)

I'm not trying to suggest how to weigh and tradeoff backward 
compatibility vs improvements to or elimination of autodecoding. 
Just trying to shed some light on why some people may have a 
different assessment of the significance of autodecoding issues.

--Jon
Nov 29 2018
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 29 November 2018 at 10:14:37 UTC, Chris wrote:

 You do realize that autodecode is an old flaw that has to go 
 sooner or later. It negatively affects string handling 
 performance, is not even correct and is a deal breaker in a 
 world where string handling is omnipresent.


Its a flaw but I wouldn't call it a deal breaker. If you want 
performance you will pay attention to details and you will see 
where autodecode happens and you can fix that.

Now Walter has asked you twice what are you proposing to do about 
autodecode that doesnt SILENTLY break existing code. Walter is a 
guy that doesnt like to be verbose and tries to express himself 
with as few words as possible. If we expand his one sentence we 
would get something like this.

I agree with you that autodecode is a problem and its a feature 
that appeared to be good on idea level. Now that its clear that 
it is a problem we thought hard on possible solutions to this 
problem and we didnt found satisfactory solution. Its possible 
that our limited brains could not have thought all possibilities 
and you might have a key to solving this problem once and for all 
so with that hope I ask you what are you proposing?

And to this you respond with


 And reasonable paths to fix it have been proposed.


What path? When proposed? Where can I read about them? And of 
those paths which one do you prefer? If you wrote one more vague 
statement like this a cute animal will die. Like this one 
https://www.youtube.com/watch?v=18-xvIjH8T4&t=20


 I'd suggest something like the "D labs" for it where you can 
 test all those great new ideas and features for a minimum of 
 one year.


You mean something like DIP? As a person who is so critical of 
everything you seem to know remarkably low on how D sausage is 
made. That came out wrong...
Nov 29 2018
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 29 November 2018 at 13:48:43 UTC, welkam wrote:

 On Thursday, 29 November 2018 at 10:14:37 UTC, Chris wrote:

 You do realize that autodecode is an old flaw that has to go 
 sooner or later. It negatively affects string handling 
 performance, is not even correct and is a deal breaker in a 
 world where string handling is omnipresent.


 Its a flaw but I wouldn't call it a deal breaker. If you want 
 performance you will pay attention to details and you will see 
 where autodecode happens and you can fix that.

 Now Walter has asked you twice what are you proposing to do 
 about autodecode that doesnt SILENTLY break existing code. 
 Walter is a guy that doesnt like to be verbose and tries to 
 express himself with as few words as possible. If we expand his 
 one sentence we would get something like this.

 I agree with you that autodecode is a problem and its a feature 
 that appeared to be good on idea level. Now that its clear that 
 it is a problem we thought hard on possible solutions to this 
 problem and we didnt found satisfactory solution. Its possible 
 that our limited brains could not have thought all 
 possibilities and you might have a key to solving this problem 
 once and for all so with that hope I ask you what are you 
 proposing?

 And to this you respond with


 And reasonable paths to fix it have been proposed.


 What path? When proposed? Where can I read about them? And of 
 those paths which one do you prefer? If you wrote one more 
 vague statement like this a cute animal will die. Like this one 
 https://www.youtube.com/watch?v=18-xvIjH8T4&t=20


 I'd suggest something like the "D labs" for it where you can 
 test all those great new ideas and features for a minimum of 
 one year.


 You mean something like DIP? As a person who is so critical of 
 everything you seem to know remarkably low on how D sausage is 
 made. That came out wrong...


Haha! That's a good one, puts reddit to shame really.

Anyway back on topic...

I think deprecating the auto decoding free functions with a 
message to use `.byChar`, `.byDchar`,`.representation` etc. is 
really the _only_ practical way forward on this. Yes its slow but 
it won't cause any breakage. Certainly not silent breakage, 
deprecation being rather noisy.
Nov 29 2018
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/29/18 9:11 AM, Nicholas Wilson wrote:

 I think deprecating the auto decoding free functions with a message to 
 use `.byChar`, `.byDchar`,`.representation` etc. is really the _only_ 
 practical way forward on this. Yes its slow but it won't cause any 
 breakage. Certainly not silent breakage, deprecation being rather noisy.


When I have free time, I'm going to do all this shit. I'm so sick of 
autodecoding, and I have a feeling it will break so little code*, that 
we are wringing our hands over nothing.

-Steve

* The big irony of autodecoding is that literally most of Phobos 
SPECIFICALLY avoids autodecoding carefully because it's such a 
performance problem. Removing autodecoding will still work with such 
workarounds.
Nov 29 2018
next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 29 November 2018 at 14:58:49 UTC, Steven 
Schveighoffer wrote:

 On 11/29/18 9:11 AM, Nicholas Wilson wrote:

 I think deprecating the auto decoding free functions with a 
 message to use `.byChar`, `.byDchar`,`.representation` etc. is 
 really the _only_ practical way forward on this. Yes its slow 
 but it won't cause any breakage. Certainly not silent 
 breakage, deprecation being rather noisy.


 When I have free time, I'm going to do all this shit. I'm so 
 sick of autodecoding, and I have a feeling it will break so 
 little code*, that we are wringing our hands over nothing.

 -Steve

 * The big irony of autodecoding is that literally most of 
 Phobos SPECIFICALLY avoids autodecoding carefully because it's 
 such a performance problem. Removing autodecoding will still 
 work with such workarounds.


That sounds good, thanks. Sure, why not give it a shot?
Nov 29 2018
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 29 November 2018 at 14:58:49 UTC, Steven 
Schveighoffer wrote:

 On 11/29/18 9:11 AM, Nicholas Wilson wrote:

 I think deprecating the auto decoding free functions with a 
 message to use `.byChar`, `.byDchar`,`.representation` etc. is 
 really the _only_ practical way forward on this. Yes its slow 
 but it won't cause any breakage. Certainly not silent 
 breakage, deprecation being rather noisy.


 When I have free time, I'm going to do all this shit. I'm so 
 sick of autodecoding, and I have a feeling it will break so 
 little code*, that we are wringing our hands over nothing.

 -Steve

 * The big irony of autodecoding is that literally most of 
 Phobos SPECIFICALLY avoids autodecoding carefully because it's 
 such a performance problem. Removing autodecoding will still 
 work with such workarounds.


Hooray!

I think adding a version like `Phobos_NoAutodecode` so it could 
be tested with https://git.ikeran.org/dhasenan/dubautotester and 
people can opt in to it, in parallel with deprecating the auto 
decoding `front/popFront`.
Nov 29 2018
parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 30 November 2018 at 00:31:55 UTC, Nicholas Wilson 
wrote:

 I think adding a version like `Phobos_NoAutodecode` so it could 
 be tested with https://git.ikeran.org/dhasenan/dubautotester 
 and people can opt in to it..


Please don't! This will likely cause some third-party libraries 
to rely on the switch, while some still rely on autodecoding, 
making them incompatible!

On the other hand, if we can find a way to similarily mark a 
single module to not autodecode while others still could, then 
it's a brilliant idea.

Otherwise, I quess we just have to plain deprectate using char 
arrays as ranges at all, or leave the whole thing as is.
Nov 30 2018
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 30 November 2018 at 11:22:04 UTC, Dukc wrote:

 [snip]

 Please don't! This will likely cause some third-party libraries 
 to rely on the switch, while some still rely on autodecoding, 
 making them incompatible!

 On the other hand, if we can find a way to similarily mark a 
 single module to not autodecode while others still could, then 
 it's a brilliant idea.

 Otherwise, I quess we just have to plain deprectate using char 
 arrays as ranges at all, or leave the whole thing as is.


Fair point.

Perhaps UDAs? I can't seem to get it to work with static ifs 
(below). Same thing with template ifs. I tried to do two 
different versions of foo, one as void foo(T)( noAutodecode T x) 
and the other with same signature as below. The problem is with 
overloads. I can't do void foo(T)(! noAutodecode T x) and get the 
right behavior. Support for UDAs on function parameters might 
need to get improved to make it convenient, but it seems like a 
natural evolution of the recent change in 2.082.

import std.traits : hasUDA, isNarrowString;
import std.stdio : writeln;

struct noAutodecode {};

void foo(T)(T x)
     if (isNarrowString!T)
{
     static if (hasUDA!(x, noAutodecode)) {
         writeln(hasUDA!(x, noAutodecode));
     } else {
         writeln(hasUDA!(x, noAutodecode));
     }
}

void main() {
     string a = "xyz";
      noAutodecode string b = "zyx";
     foo(a); //prints false
     foo(b); //prints false, expected true
}
Nov 30 2018
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 30 November 2018 at 16:05:18 UTC, jmh530 wrote:

 import std.traits : hasUDA, isNarrowString;
 import std.stdio : writeln;

 struct noAutodecode {};

 void foo(T)(T x)
     if (isNarrowString!T)
 {
     static if (hasUDA!(x, noAutodecode)) {
         writeln(hasUDA!(x, noAutodecode));
     } else {
         writeln(hasUDA!(x, noAutodecode));
     }
 }

 void main() {
     string a = "xyz";
      noAutodecode string b = "zyx";
     foo(a); //prints false
     foo(b); //prints false, expected true
 }


UDAs attach to symbols, not values, so x will never have a 
 noAutodecode attribute, no matter what arguments you pass to foo.
Nov 30 2018
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 30 November 2018 at 16:54:43 UTC, Paul Backus wrote:

 [snip]

 UDAs attach to symbols, not values, so x will never have a 
  noAutodecode attribute, no matter what arguments you pass to 
 foo.


Yeah you're right. Putting the attribute on the function 
parameter gives the parameter that attribute (the function spec 
says to look at the UDA spec and then that doesn't really say 
anything about function parameters).  It doesn't require that the 
parameter has that attribute.

The only thing I could think of was doing it with an alias, but 
it's a little too ugly to get the right behavior. Maybe there's a 
more elegant way?

import std.traits : hasUDA;
import std.stdio : writeln;

struct noAutodecode {};

void foo(alias x, T)(T y)
     if (hasUDA!(x, noAutodecode))
{
     writeln("here");
}

void foo(alias x, T)(T y)
     if (!hasUDA!(x, noAutodecode))
{
     writeln("there");
}


void main() {
     string a = "xyz";
      noAutodecode string b = "zyx";
     foo!(a, string)(a);
     foo!(b, string)(b);
}
Nov 30 2018
prev sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Friday, 30 November 2018 at 11:22:04 UTC, Dukc wrote:

 On Friday, 30 November 2018 at 00:31:55 UTC, Nicholas Wilson 
 wrote:

 I think adding a version like `Phobos_NoAutodecode` so it 
 could be tested with 
 https://git.ikeran.org/dhasenan/dubautotester and people can 
 opt in to it..


 Please don't! This will likely cause some third-party libraries 
 to rely on the switch, while some still rely on autodecoding, 
 making them incompatible!

 On the other hand, if we can find a way to similarily mark a 
 single module to not autodecode while others still could, then 
 it's a brilliant idea.

 Otherwise, I quess we just have to plain deprectate using char 
 arrays as ranges at all, or leave the whole thing as is.


Just thinking loud: if the libraries are incompatible and you get 
an error while trying to use them together, that would be a good 
thing. There is no silent breakage. The third party library 
authors can be be contacted and asked to update their libraries.

Kind regards
Andre
Nov 30 2018
parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 30 November 2018 at 18:16:37 UTC, Andre Pany wrote:

 Just thinking loud: if the libraries are incompatible and you 
 get an error while trying to use them together, that would be a 
 good thing. There is no silent breakage. The third party 
 library authors can be be contacted and asked to update their 
 libraries.


In that way, yes, a good thing. But I completely disagree with it 
being a good idea nonetheless. The problem isn't that the 
libraries need to be updated, the problem is that they need to do 
so immediately.

For library upkeepers, such global versioning would be 
effectively as bad as just removing autodecoding overnight 
without any deprectation period. Or perhaps even worse, since 
they would probably have to leave behind compatibility with 
autodecoding version, as there are always libraries that won't 
migrate quickly enough.

Of course, we could say that the libraries, when they migrate, 
need to keep backwards compatibility, so late migrators will keep 
working. But I can hardly imagine that every library keeper will 
bother and remember to test both versions.
Nov 30 2018
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/30/18 1:41 PM, Dukc wrote:

 On Friday, 30 November 2018 at 18:16:37 UTC, Andre Pany wrote:

 Just thinking loud: if the libraries are incompatible and you get an 
 error while trying to use them together, that would be a good thing. 
 There is no silent breakage. The third party library authors can be be 
 contacted and asked to update their libraries.


 
 In that way, yes, a good thing. But I completely disagree with it being 
 a good idea nonetheless. The problem isn't that the libraries need to be 
 updated, the problem is that they need to do so immediately.
 
 For library upkeepers, such global versioning would be effectively as 
 bad as just removing autodecoding overnight without any deprectation 
 period. Or perhaps even worse, since they would probably have to leave 
 behind compatibility with autodecoding version, as there are always 
 libraries that won't migrate quickly enough.
 
 Of course, we could say that the libraries, when they migrate, need to 
 keep backwards compatibility, so late migrators will keep working. But I 
 can hardly imagine that every library keeper will bother and remember to 
 test both versions.


There are going to be many cases I think where it just works, no matter 
what you care about auto-decoding.

For example searching for a string in a string doesn't matter whether 
the string uses auto-decoding or not.

For low-level code, you need to pick autodecoding or not autodecoding, 
and we need a deprecation period, Like Nick suggested. This means that 
for a period of time, a string won't be a range(!), you have to select 
byCodeUnit or byCodePoint (or similar). I think to make things easier, 
we can provide convenience aliases (like bcp or bcu), so it's not as 
painful. We will likely have workarounds all throughout phobos, that 
will then be removed once the deprecation period is over.

But painful, it will be. However, mostly for low-level code (i.e. code 
that uses string.front and string.popFront). May want low-level code 
conveniences too (frontCodeUnit, frontCodePoint?)

However, the end result is after the deprecation period, things can go 
back to being reasonable, and autodecoding-free.

We will see how bad it is, once it's tried. I'm hoping not very bad.

-Steve
Nov 30 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 30, 2018 at 02:08:28PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
[...]

 There are going to be many cases I think where it just works, no
 matter what you care about auto-decoding.
 
 For example searching for a string in a string doesn't matter whether
 the string uses auto-decoding or not.
 
 For low-level code, you need to pick autodecoding or not autodecoding,
 and we need a deprecation period, Like Nick suggested.


[...]

 However, the end result is after the deprecation period, things can go
 back to being reasonable, and autodecoding-free.
 
 We will see how bad it is, once it's tried. I'm hoping not very bad.


[...]

There have been offers to run an experiment on various CI's and
code.dlang.org, which will give us concrete data on just how bad this
will be.  Care to throw together a Phobos PR that can be used as a
yardstick?

Basically, I can see multiple runs of the experiment, i.e., PRs that do
slightly different things, to probe various aspects of this:

1) Silent breakage: just turn off autodecoding silently, run the CI's,
see how many unittests break. (Hopefully not zero! Otherwise that means
most D code sux. :D)  Examine breakages to assess ease level of fix.
E.g., if we just have to add .byCodeUnit or .byCodePoint, it would count
as an easy fix, whereas if the algorithm needs to be rewritten, then
it's a complex fix.  Tally both kinds of fixes and see how the numbers
compare.

2) Deprecation breakage: add a deprecation to all entry points to
autodecoding. See how much code breaks. Examine breakages to assess ease
of fix. Should be similar to silent breakage. If numbers are much
bigger, that means most D code sux. :D

3) Make strings non-ranges: this will probably basically break
*everything*.  Subtract the numbers from (1) and (2) to get an idea of
how much extra work will be required during the deprecation period.
Essentially, this tells us how much work it will be to add .byCodeUnit /
.byCodePoint to every iteration over string.  Expect pretty bad numbers
here. (But if we get a pleasant surprise here, this may be an indication
that removing autodecoding isn't as fearful as we thought!)

Of course, all of the above depends on a base PR that fixes Phobos to be
passing CI tests first.  Alternatively, we could perform the above steps
on Phobos first, to assess how much work it will be to make Phobos
autodecoding-free, before trying it on user code.


T

-- 
Life begins when you can spend your spare time programming instead of watching
television. -- Cal Keegan
Nov 30 2018
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 30 November 2018 at 19:08:28 UTC, Steven Schveighoffer 
wrote:

 For low-level code, you need to pick autodecoding or not 
 autodecoding, and we need a deprecation period, Like Nick 
 suggested. This means that for a period of time, a string won't 
 be a range(!).


If that's what he intended, better. Libraries still need to 
adapt, but at least won't become incompatible with each other 
overnight.


 But painful, it will be. However, mostly for low-level code 
 (i.e. code that uses string.front and string.popFront). May 
 want low-level code conveniences too (frontCodeUnit, 
 frontCodePoint?)


I think it's not only low-level code. When I'm just coding away 
some user input handling, I don't always bother to add 
.byCodeUnit everywhere. For many, including me, the change will 
be mainly a good thing, since there will be no accidental 
decoding anymore -I'll happily migrate. But there are, without 
doubt, codebases in production that have thousands of lines full 
of auto-decoding, maintained by people who hardly time to update.


 We will see how bad it is, once it's tried. I'm hoping not very 
 bad.


The good news is, I think, that we can try this without knowing 
in advance whether it can be done. We can deprectate 
autodecoding, but if it proves to be too tough to adapt, we 
simply won't remove it after the period. Of course, we should say 
in advance that we're only considering removing it, otherwise we 
might scare some users away.
Nov 30 2018
prev sibling next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 29 November 2018 at 14:11:30 UTC, Nicholas Wilson 
wrote:

 I think deprecating the auto decoding free functions with a 
 message to use `.byChar`, `.byDchar`,`.representation` etc. is 
 really the _only_ practical way forward on this. Yes its slow 
 but it won't cause any breakage. Certainly not silent breakage, 
 deprecation being rather noisy.


People dont like braking changes because they add additional work 
for already working code. If we made a tool that would 
automagically translate deprecated usages to newer once it might 
be easier sell to users. The problem is that such tool requires 
work
Nov 29 2018
parent reply M.M. <matus email.cz> writes:
On Thursday, 29 November 2018 at 15:36:48 UTC, welkam wrote:

 On Thursday, 29 November 2018 at 14:11:30 UTC, Nicholas Wilson 
 wrote:

 I think deprecating the auto decoding free functions with a 
 message to use `.byChar`, `.byDchar`,`.representation` etc. is 
 really the _only_ practical way forward on this. Yes its slow 
 but it won't cause any breakage. Certainly not silent 
 breakage, deprecation being rather noisy.


 People dont like braking changes because they add additional 
 work for already working code. If we made a tool that would 
 automagically translate deprecated usages to newer once it 
 might be easier sell to users. The problem is that such tool 
 requires work


Could such an automated tool be done, in principle, for handling 
autodecode in existing code?
Nov 29 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Thu, 29 Nov 2018 16:13:59 +0000, M.M. wrote:

 Could such an automated tool be done, in principle, for handling
 autodecode in existing code?


Yes, but it's going to be awkward. You'd need to add a std.range function 
like "noAutoDecode" and wrap everything that's iterated unless you can 
prove it's not a string or wstring.
Nov 29 2018
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 29 November 2018 at 14:11:30 UTC, Nicholas Wilson 
wrote:

 [snip]

 I think deprecating the auto decoding free functions with a 
 message to use `.byChar`, `.byDchar`,`.representation` etc. is 
 really the _only_ practical way forward on this. Yes its slow 
 but it won't cause any breakage. Certainly not silent breakage, 
 deprecation being rather noisy.


Whatever is decided, just have a clear process that minimizes 
problems and can be communicated to D programmers of all levels.

IMO, a good first step would be versioning autodecoding, so that 
autodecoding or non-autodecoding can be decided at the command 
line. Then make it so that the autodecoding free functions are 
only called when the autodecoding version is used. This is 
something that can be done without breaking any code if the 
version is set to autodecoding. Of course, setting the version to 
nonautodecoding means that anywhere you pass a string to one of 
those range functions should fail at compile-time (an improved 
error message could be added to point users to byChar/etc). Next, 
some unlucky soul can go through phobos and ensure that tests 
pass regardless what version is used, preferably with the help of 
some kind of automatic tool. I think then D could switch the 
default from autodecoding to non-autodecoding. And then deprecate 
autodecoding if necessary.
Nov 29 2018
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 29 November 2018 at 13:48:43 UTC, welkam wrote:

 On Thursday, 29 November 2018 at 10:14:37 UTC, Chris wrote:



 And reasonable paths to fix it have been proposed.


 What path? When proposed? Where can I read about them? And of 
 those paths which one do you prefer? If you wrote one more 
 vague statement like this a cute animal will die. Like this one 
 https://www.youtube.com/watch?v=18-xvIjH8T4&t=20


You're either new to Dlang or pretend that you don't know. There 
have been proposals by Steven Schveighoffer, H.S. Teoh, Ola and 
many others as to how to tackle it over the years. I will not 
repeat them here, and I think Steven actually has a plan.


 I'd suggest something like the "D labs" for it where you can 
 test all those great new ideas and features for a minimum of 
 one year.


 You mean something like DIP? As a person who is so critical of 
 everything you seem to know remarkably low on how D sausage is 
 made. That came out wrong...


Definitely not like Dips.

"DLab": an experimental _actual_ version of D (dmd) that has all 
the fancy new radical ideas and features, but that is not the 
official release, but a lab version for those who requested or 
came up with new features / radical ideas, where they can test if 
all the stuff they came up with really works / is worth it.

If people knew how laws and D are made...and this has to change 
in my opinion. You've just admitted yourself that D is made like 
the proverbial sausages - better not ask, you don't really want 
to know what's in them. Right o! I wouldn't mind, really, if it 
wasn't for the odd food poisoning.

Here's a suggestion:

1. DTox: create a clean, stable and reliable version of D
2. DLab: have a playground for ideas and see what happens, but 
keep it separate from 3.
3. DLang: the official language that ships with LTS and certain 
guarantees.

And who knows, once we have 3. maybe people will start to help 
with building tools and write libs for D? I think I've made my 
point of view clear over the last couple of months. I'm not 
asking for much, just structure. And structure has nothing to do 
with "limited resources". (I cannot afford a room cleaner, so 
that's why my room's a mess ;). And to make this clear once and 
for all, I've never asked for new language features as far as I 
remember, only for stability and the payment of old debts (see 
points 1. & 2.) End of.
Nov 29 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 29 November 2018 at 16:50:42 UTC, Chris wrote:

 You mean something like DIP? As a person who is so critical of 
 everything you seem to know remarkably low on how D sausage is 
 made. That came out wrong...


 Definitely not like Dips.


You need one if you want to deprecate a language feature. There 
is no alternative afaik.
Nov 29 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy wrote:

 You need one if you want to deprecate a language feature. There 
 is no alternative afaik.


autodecode is not a language feature. It is a library function 
that is only called by other library functions.
Nov 29 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 29 November 2018 at 18:40:13 UTC, Adam D. Ruppe 
wrote:

 On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy 
 wrote:

 You need one if you want to deprecate a language feature. 
 There is no alternative afaik.


 autodecode is not a language feature. It is a library function 
 that is only called by other library functions.


Yet everyone here acts like it is a major deprecation, with 
different opinions on how to handle it.
Nov 29 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, November 29, 2018 12:54:34 PM MST 12345swordy via Digitalmars-d 
wrote:

 On Thursday, 29 November 2018 at 18:40:13 UTC, Adam D. Ruppe

 wrote:

 On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy

 wrote:

 You need one if you want to deprecate a language feature.
 There is no alternative afaik.


 autodecode is not a language feature. It is a library function
 that is only called by other library functions.


 Yet everyone here acts like it is a major deprecation, with
 different opinions on how to handle it.


It _is_ major. What Nicholas has proposed would break almost all
string-related code in the entire D ecosystem. It would not be silent
breakage, and because it involves deprecations, no one would have to update
their code immediately, but a _ton_ of code would have to be updated - even
code that would work just fine if we were to just switch to treating strings
as ranges of code units. And given the insane number of deprecation messages
that it would cause, I'm willing to bet that a _lot_ of folks would simply
start compiling with the flag to get rid of deprecation messages rather than
updating their code, which would make the point when the functions were
actually removed rather interesting. It's quite possible that that huge
disruption would be worth it given that it would allow us to get rid of
autodecoding, but there's no question that it's huge. The magnitude of the
breakage would dwarf anything that we've done in years.

That being said, it's still a library change, not a language change, and
DIPs are for proposing language changes, not library changes. So, a DIP
should not be necessary. Given the magnitude of the change and the code that
it would be changing, Andrei would likely need to approve the PR, but it
would still just be a PR (or set of PRs if necessary).

- Jonathan M Davis
Nov 29 2018
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/29/18 2:54 PM, 12345swordy wrote:

 On Thursday, 29 November 2018 at 18:40:13 UTC, Adam D. Ruppe wrote:

 On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy wrote:

 You need one if you want to deprecate a language feature. There is no 
 alternative afaik.


 autodecode is not a language feature. It is a library function that is 
 only called by other library functions.


 
 Yet everyone here acts like it is a major deprecation, with different 
 opinions on how to handle it.


It is a major deprecation. The largest problem would be that strings all 
of a sudden would have an element type of char. I still think Phobos 
will handle this properly (or can be made to quite easily), but other 
code might not be so lucky.

But I don't know whether it requires a DIP or not. In any case, I'm 
going to try removing it and see what breaks. If the PR to "remove 
autodecode" from Phobos isn't that hairy, it may put a different light 
on what breakage may happen.

-Steve
Nov 29 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2018 at 01:21:50PM -0700, Jonathan M Davis via Digitalmars-d
wrote:

 On Thursday, November 29, 2018 12:54:34 PM MST 12345swordy via Digitalmars-d 
 wrote:

 On Thursday, 29 November 2018 at 18:40:13 UTC, Adam D. Ruppe




[...]

 autodecode is not a language feature. It is a library function
 that is only called by other library functions.


 Yet everyone here acts like it is a major deprecation, with
 different opinions on how to handle it.


 
 It _is_ major. What Nicholas has proposed would break almost all
 string-related code in the entire D ecosystem. It would not be silent
 breakage, and because it involves deprecations, no one would have to
 update their code immediately, but a _ton_ of code would have to be
 updated - even code that would work just fine if we were to just
 switch to treating strings as ranges of code units.


Y'know, we keep talking about how huge a breakage removing autodecoding
would cause, but have we ever quantified our claim/belief?  What about
this little experiment:

Since we already have CI setup to test a good number of major D
codebases, how about we create a test environment (could be as simple as
just a PR -- mark it "do not merge" or whatever) that removes
autodecoding.  Let the CI run, and tell us just how big the actual
breakage is.  Presumably, "good" D codebases also ought to have
sufficient unittests that any subtle breakage caused by strings being
ranges of char rather than dchar would be caught as a unittest failure
rather than silently ignored.

Now, of course, the D code tested by CI is only a subset of all D code
out there, but surely it should be a sufficiently generic representation
of your average D code in the wild.  We could add the projects on
code.dlang.org to the list, plus any other projects the forumites here
might be interested to add to this experiment.  This should give us a
pretty good idea of just how big of a breakage we're talking about, and
what kind of issues we might face were we to actually go ahead with
removing autodecoding.

Once we have this data, perhaps it would help us get off the fence about
autodecoding.  It's entirely possible that the actual breakage that
would be caused will actually be much less than we fear.  This
experiment will help allay those unfounded fears -- or confirm them, if
the scope of breakage really is as large as everyone keeps saying.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Nov 29 2018
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 29 November 2018 at 21:21:19 UTC, H. S. Teoh wrote:

 Y'know, we keep talking about how huge a breakage removing 
 autodecoding would cause, but have we ever quantified our 
 claim/belief?  What about this little experiment:


Sounds like a job for 
https://git.ikeran.org/dhasenan/dubautotester
Nov 29 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thu, 29 Nov 2018 21:33:08 +0000, Paul Backus wrote:

 On Thursday, 29 November 2018 at 21:21:19 UTC, H. S. Teoh wrote:

 Y'know, we keep talking about how huge a breakage removing autodecoding
 would cause, but have we ever quantified our claim/belief?  What about
 this little experiment:


 
 Sounds like a job for https://git.ikeran.org/dhasenan/dubautotester


Got a patch?
Nov 29 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Thu, 29 Nov 2018 21:58:55 +0000, Neia Neutuladh wrote:

 On Thu, 29 Nov 2018 21:33:08 +0000, Paul Backus wrote:

 Sounds like a job for https://git.ikeran.org/dhasenan/dubautotester


 
 Got a patch?


By which I mean, do you have a druntime / phobos patch to test out? 
Because I've hacked up support for exercising experimental compilers.
Nov 29 2018
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 29 November 2018 at 21:21:19 UTC, H. S. Teoh wrote:

 [snip]

 Since we already have CI setup to test a good number of major D 
 codebases, how about we create a test environment (could be as 
 simple as just a PR -- mark it "do not merge" or whatever) that 
 removes autodecoding. ...


I was thinking the same thing...just removing the string 
specialized range primitives doesn't take a lot of work (I 
discussed a strategy above that leaves those functions but 
changes behavior based on a version statement).
Nov 29 2018
prev sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
It seems you are right, I have a feeling that this code use autodecoding:
foreach(c; someString){...}

but it seems it does not

https://run.dlang.io/is/YGgigJ

On Thu, Nov 29, 2018 at 7:45 PM Adam D. Ruppe via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy wrote:

 You need one if you want to deprecate a language feature. There
 is no alternative afaik.


 autodecode is not a language feature. It is a library function
 that is only called by other library functions.
Nov 29 2018
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 29 November 2018 at 21:11:20 UTC, Daniel Kozak wrote:

 It seems you are right, I have a feeling that this code use 
 autodecoding:
 foreach(c; someString){...}

 but it seems it does not


Indeed, it iterates over the chars.

You can *request* decoding with

foreach(dchar c; someString) {...}

but that's not auto (nor does it use the library facility, that 
is actually built in)
Nov 29 2018
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 28 November 2018 at 00:12:15 UTC, Walter Bright 
wrote:

 The issue of prioritization of reviewing PRs, etc, perennially 
 comes up and has done so again recently:

 https://digitalmars.com/d/archives/digitalmars/D/It_is_the_year_2020_why_should_I_use_learn_D_321380.html#N321572

 It seems we're not the only group struggling with this issue. 
 Food for thought, and some controversy:

 https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

 https://gist.github.com/halgari/c17f378718cbd2fd82324002133ef678#gistcomment-2768338

 https://news.ycombinator.com/item?id=18538123


I saw this, but I do think their situation is somewhat different, 
at least based on my Clojure usage around maybe 2011-2013.

Their development model seemed to be more like SQLite, where 
they'll call you if they want you to contribute, but they don't 
really ever call because they want to do it themselves. The D 
development model is AFAICT to get as many contributions from as 
many people as possible.
Nov 28 2018
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Wednesday, 28 November 2018 at 00:12:15 UTC, Walter Bright 
wrote:

 It seems we're not the only group struggling with this issue.


Because people are people. Now we can leave it at that or maybe 
take Jocko Willink approach of extreme ownership. If my PR would 
stall it would be my fault because I didnt put enough effort in 
making it easy to review. A PR reviewer should look at the same 
situation and say to them self "its my fault that this PR dint 
get merged or closed because <insert reasons here>

If a person submits a change that core team didnt wanted then 
they should think that its their fault for not communicating 
clear enough.

I didnt found good clip of him talking about this stuff but found 
other that might be useful for leaders. 
https://www.youtube.com/watch?v=yGBj2xAnqE8
Nov 29 2018
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Wednesday, 28 November 2018 at 00:12:15 UTC, Walter Bright 
wrote:

 It seems we're not the only group struggling with this issue. 
 Food for thought, and some controversy:

 https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9


Every word Rich wrote there is true... Again he proves (again) he 
is a true genius...
Dec 04 2018