November 29, 2018
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.
November 29, 2018
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
November 29, 2018
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
November 29, 2018
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?
November 29, 2018
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?
November 29, 2018
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.
November 29, 2018
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.
November 29, 2018
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.
November 29, 2018
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.
November 29, 2018
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.