On Thursday, 2 June 2016 at 13:11:10 UTC, Steven Schveighoffer wrote:
> This means that a string is a range. What is it a range of? If you want to make it a range of code units, I think you will lose that battle.

After the first migration step joiner will return a decoded dchar range just like it does now, only code will change internally, there will be no observable semantic difference to the user. Anyway, read Walter's proposal in the thread about dealing with autodecode.

On 06/02/2016 10:53 AM, Kagamin wrote:
> On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu wrote:
>> This is what's happening here. We worked ourselves to a foam because
>> the creator of the language started a thread entitled "The Case
>> Against Autodecode", whilst fully understanding there is no way to
>> actually eliminate autodecode.
>
> Autodecode doesn't need to be removed from phobos completely, it only
> needs to be more bearable, like it is in the foreach statement. E.g.
> byDchar will stay, initial idea is to actually put it to more intensive
> usage in phobos and user code, no need to remove it.

Yah, and then such code will work with RCStr. -- Andrei

On 06/02/2016 10:48 AM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jun 02, 2016 at 09:06:44AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> [...]
>> ZombineDev, I've been at the top level in the C++ community for many
>> many years, even after I wanted to exit :o). I'm familiar with how the
>> committee that steers C++ works, perspective that is unique in our
>> community - even Walter lacks it. I see trends and patterns. It is
>> interesting how easily a small but very influential priesthood can
>> alienate itself from the needs of the larger community and get into a
>> frenzy over matters that are simply missing the point.
>
> Appeal to authority.

You cut the context, which was rampant speculation.

>> This is what's happening here. We worked ourselves to a foam because
>> the creator of the language started a thread entitled "The Case
>> Against Autodecode", whilst fully understanding there is no way to
>> actually eliminate autodecode.
>
> I think that's a misrepresentation of the situation.  I was getting
> increasingly unhappy with autodecoding myself, completely independently
> of Walter, and in fact have filed bugs and posted complaints about it
> long before Walter started his thread.  I used to be a supporter of
> autodecoding, but over time it has become increasingly clear to me that
> it was a mistake.  The fact that you continue to deny this and write it
> off in the face of similar complaints raised by many active D users is
> very off-putting, to say the least, and does not inspire confidence. Not
> to mention the fact that you started this thread yourself with a
> question about what it is we dislike about autodecoding, yet after
> having received a multitude of complaints, corrobated by many forum
> members, you simply write off the whole thing like it was nothing.  If
> you want D to succeed, you need to raise the morale of the community,
> and this is not the way to raise morale.

There is no denying. If I did things all over again, autodecoding would not be in. But also string would not be immutable(char)[] which is the real mistake.

Some of the arguments in here have been good, but many (probably the majority) of them were not so much. A good one didn't even come up, Walter told it to me over the phone: the reality of invalid UTF strings forces you to mind the representation more often than you'd want in an ideal world.

There is no "writing off". Again, the real solution here is RCStr. We can't continue with immutable(char)[] as our flagship string. Autodecoding is the least of its problems.

>> The very definition of a useless debate, the kind he and I had agreed
>> to not initiate anymore. It was a mistake. I'm still metaphorically
>> angry at him for it.
>
> On the contrary, I found that Walter's willingness to admit past
> mistakes very refreshing, even if practically speaking we can't actually
> get rid of autodecoding today.  What he proposed in the other thread is
> actually a workable step towards reversing the wrong decision behind
> autodecoding, that doesn't leave existing users out in the cold, and
> that we might actually be able to pull off if done carefully.  I know
> you probably won't see it the same way, since you still seem convinced
> that autodecoding was a good idea, but you need to understand that your
> opinion is not representative in this case.

I don't see it the same way. Yes, I agree my opinion is not representative. I'd also say I'm glad I can do something about this.

> [...]
>> Meanwhile, I go to conferences. Train and consult at large companies.
>> Dozens every year, cumulatively thousands of people. I talk about D
>> and ask people what it would take for them to use the language.
>> Invariably I hear a surprisingly small number of reasons:
>>
>> * The garbage collector eliminates probably 60% of potential users
>> right off.
>
> At least we have begun to do something about this. That's good news.

I've been working on RCStr for the past few days. I'd get a lot more work done if I didn't need to talk sense into people in this thread.

>> * Tooling is immature and of poorer quality compared to the
>> competition.
>
> And what have we done about it? How long has it been since dfix existed,
> yet we still haven't really integrated it into the dmd toolchain?

I've spoken to Brian about it. Dfix does not do lookup, which makes it sadly not up for meaningful uses.

>> * Safety has holes and bugs.
>
> And what have we done about it?

Walter and I are working on safe RC.

>> * Hiring people who know D is a problem.
>
> There are many willing candidates right here. :-P

Nice.

>> * Documentation and tutorials are weak.
>
> And what have we done about this?

http://tour.dlang.org is a good start.

>> * There's no web services framework (by this time many folks know of
>> D, but of those a shockingly small fraction has even heard of vibe.d).
>> I have strongly argued with Sönke to bundle vibe.d with dmd over one
>> year ago, and also in this forum. There wasn't enough interest.
>
> What about linking to it in a prominent place on dlang.org?  This isn't
> a big problem, AFAICT.  I don't think it takes months and years to put
> up a big prominent banner promoting vibe.d on, say, the download page of
> dlang.org.

PR please. I can't babysit everything. I'm preparing for a conference where I'll evangelize for D next week (http://ndcoslo.com/speaker/andrei-alexandrescu/). As I mentioned at DConf, for better or worse this is the kind of stuff I cannot delegate.

That kind of work is where the community would really make an impact, not a large debate that I need to worry will lead to some silly rash decision.

>> * (On Windows) if it doesn't have a compelling Visual Studio plugin,
>> it doesn't exist.
>
> And what have we done about this?

I'm actively looking for a collaboration.

> One of the things that I have found a little disappointing with D is
> that while it has many very promising features, it lacks polish in many
> small details. Such as the way features interact with each other in
> corner cases. E.g., the whole can't-use-gc from dtor debacle, the
> semantics of closures over aggregate members, holes in @safe, holes in
> const/immutable in unions, the whole import mess that took
> oh-how-many-years to clean up that thankfully was finally improved
> recently, can't use @nogc with Phobos, can't use const/pure/etc. in
> Object.toString, Object.opEqual, et al (which we've been trying to get
> of since how many years ago now?), and a whole long list of small
> irritations that in themselves are nothing, but together add up like a
> dustball to an overall perception of lack of polish.

It's a fair perspective. Those annoy me as well. I'll also note every language has such matter, including the mainstream ones. At some point we need to acknowledge they're there but they're small enough to live with. (Some of those you enumerated aren't small, e.g. the holes in @safe.)

> I'm more sympathetic to Walter's stance of improving the language for
> *current* users, instead of bending over backwards to please would-be
> adopters who may never actually adopt the language -- they'd just come
> back with new excuses of why they can't adopt D yet. If you make
> existing users happier, they will do all the work of evangelism for you,
> instead of you having to fight the uphill battle by yourself while
> bleeding away current users due to poor morale.

We want to improve the language for current AND future users. RCStr is part of that.


Andrei

On Thursday, 2 June 2016 at 15:02:13 UTC, Andrei Alexandrescu wrote:
> Yah, this is a bummer and one of the larger issues of our community: there's too much talking about doing things and too little doing things.

We wrote a PR to implement the first step in the autodecode deprecation cycle. Granted, it wasn't ready to merge, but you just closed it with a flippant "not gonna happen" despite the *unanimous* agreement that the status quo sucks, and now complain that there's too much talking and too little doing!

When we do something, you just shut it down then blame us. What's even the point of trying anymore?

On Thursday, 2 June 2016 at 15:38:46 UTC, Adam D. Ruppe wrote:
> On Thursday, 2 June 2016 at 15:02:13 UTC, Andrei Alexandrescu wrote:
>> Yah, this is a bummer and one of the larger issues of our community: there's too much talking about doing things and too little doing things.
>
> We wrote a PR to implement the first step in the autodecode deprecation cycle. Granted, it wasn't ready to merge, but you just closed it with a flippant "not gonna happen" despite the *unanimous* agreement that the status quo sucks, and now complain that there's too much talking and too little doing!
>
> When we do something, you just shut it down then blame us. What's even the point of trying anymore?

https://www.youtube.com/watch?v=MJiBjfvltQw

On Thursday, 2 June 2016 at 15:38:46 UTC, Adam D. Ruppe wrote:
> We wrote a PR to implement the first step in the autodecode deprecation cycle.

It outright deprecated popFront - that's not the first step in the migration.

On Thursday, June 02, 2016 09:06:44 Andrei Alexandrescu via Digitalmars-d wrote:
> Meanwhile, I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons:

Are folks going to not start using D because of auto-decoding? No, because they won't know anything about it. Many of them don't even know anything about ranges. But it _will_ result in a WTF moment for pretty much everyone. It happens all the time and results in plenty of questions on D.Learn and stackoverflow, because no one expects it, and it causes them problems.

Can we sanely remove auto-decoding from Phobos? I don't know. It's entrenched enough that doing so without breaking code is going to be very difficult. But at minimum, we need to mitigate it's effects, and I'm sure that we're going to be sorry in the long run if we don't figure out how to actually excise it. It's already a major wart that causes frequent problems, and it's the sort of thing that's going to make a number of folks unhappy with D in the long run, even if you can convince them to switch to it now while auto-decoding is still in place. Will it make them unhappy enough to switch away from D? Probably not. But it is going to be a constant pain point of the sort that folks frequently complain about with C++ - only this is one that we'll have, and C++ won't.

- Jonathan M Davis

On Thursday, 2 June 2016 at 15:50:54 UTC, Kagamin wrote:
> It outright deprecated popFront - that's not the first step in the migration.

Which gave us the list of places inside Phobos to fix, only about two hours of work, and proved that the version() method was viable (and REALLY easy to implement).

On 06/02/2016 11:38 AM, Adam D. Ruppe wrote:
> On Thursday, 2 June 2016 at 15:02:13 UTC, Andrei Alexandrescu wrote:
>> Yah, this is a bummer and one of the larger issues of our
>> community: there's too much talking about doing things and too
>> little doing things.
>
> We wrote a PR to implement the first step in the autodecode
> deprecation cycle. Granted, it wasn't ready to merge, but you just
> closed it with a flippant "not gonna happen" despite the *unanimous*
> agreement that the status quo sucks, and now complain that there's
> too much talking and too little doing!

You mean https://github.com/dlang/phobos/pull/4384, the one with "[do
not merge]" in the title?

Would you realistically have advised me to merge it?

I spent time writing what I thought was a reasonable and reasonably long
answer. Allow me to quote it below:

> @wilzbach thanks for running this experiment.
>
>> Andrei is wrong.
>
> Definitely wouldn't be the first time and not the last.
>
>> We can all see it, and maybe if we demonstrate that a migration
>> path is possible, even actually pretty easy following a simple
>> deprecation path, maybe he can see it too.
>
> I'm not sure who "all" is but that's beside the point. Taking a step
> back, we'd take in a change that breaks Phobos in 132 places only if
> it was a major language overhaul bringing dramatic improvements to
> the quality of life for D programmers. An artifact as earth
> shattering as ranges, or an ownership system that was massively
> simple and beneficial. For comparison, the recent changes in name
> lookup broke Phobos in fewer places (I don't have an exact number,
> but I think they were at most a couple dozen.) Those changes were
> closing an enormous hole in the language and mark a huge step
> forward. I'd be really hard pressed to characterize the elimination
> of autodecoding as enough of an improvement to warrant this kind of
> breakage. (I do realize there's a difference between breakage and
> deprecation, but for many folks the distinction is academic.)
>
> The better end game here is to improve efficiency of code that uses
> autodecoding (e.g. per the recent `find()` work), and to make sure
> `RCStr` is the right design. A string that manages its own memory
> _and_ does the right things with regard to Unicode is the ticket.
> Let's focus future efforts on that.

Could you please point me at the parts you found flippant in it, or merely unreasonable?

> When we do something, you just shut it down then blame us. What's
> even the point of trying anymore?

At some point I need to stick with what I think is the better course for D, even if that means disagreeing with you. But I hope you understand this is not "flippant" or teasing people then shutting down their good work.


Andrei

On Thursday, 2 June 2016 at 15:06:20 UTC, Andrei Alexandrescu wrote:
>> Autodecode doesn't need to be removed from phobos completely, it only
>> needs to be more bearable, like it is in the foreach statement. E.g.
>> byDchar will stay, initial idea is to actually put it to more intensive
>> usage in phobos and user code, no need to remove it.
>
> Yah, and then such code will work with RCStr. -- Andrei

Yes, do consider Walter's proposal, it will be an enabling technology for RCStr too: the more phobos works with string-like ranges the more it is usable for RCStr.