On 06/02/2016 11:58 AM, Jonathan M Davis via Digitalmars-d wrote:
> 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.

Actually ranges are a major reason for which people look into D. -- Andrei

On 06/02/2016 12:14 PM, Kagamin wrote:
> 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.

Walter and I have a unified view on this. Although I'd need to raise the issue that the primitive should be by!dchar, not byDchar. -- Andrei

On Thursday, 2 June 2016 at 16:02:18 UTC, Adam D. Ruppe wrote:
> 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).

Yes, it was a research PR that was never meant to be an implementation of the first step. You used wrong wording that just unnecessarily freaked Andrei out.

On 06/02/2016 12:45 PM, Kagamin wrote:
> On Thursday, 2 June 2016 at 16:02:18 UTC, Adam D. Ruppe wrote:
>> 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).
>
> Yes, it was a research PR that was never meant to be an implementation
> of the first step. You used wrong wording that just unnecessarily
> freaked Andrei out.

I closed it because it wasn't an actual implementation, in full understanding that the discussion in it could continue. -- Andrei

On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu wrote:
> That's not going to work. A false impression created in this thread has been that code points are useless

They _are_ useless for almost anything you can do with strings. The only places where they should be used are std.uni and std.regex.

Again: What is the justification for using code points, in your opinion? Which practical tasks are made possible (and work _correctly_) if you decode to code points, that don't already work with code units?

On Thursday, 2 June 2016 at 16:12:01 UTC, Andrei Alexandrescu wrote:
> Would you realistically have advised me to merge it?

Not at this time, no, but I also wouldn't advise you to close it and tell us to stop trying if you were actually open to a chance.

You closed that and posted this at about the same time:

http://forum.dlang.org/post/nii497$2p79$1@digitalmars.com

"I'm not going to debate this further"

"What's important is that autodecoding is here to stay - there's no realistic way to eliminate it from D."


So, what do you seriously expect us to think? We had a migration plan and enough excitement to start working on the code, then within about 15 minutes of each other, you close the study PR and post that the discussion is over and your mistake is here to stay.

> I'm not sure who "all" is but that's beside the point.


This sentence makes me pretty mad too. This topic has come up  many times and nobody, NOBODY, with the exception of yourself agrees with the current behavior anymore. It is a very frequently asked question among new users, and we have no real justification because there is no technical merit to it.

On 06/02/2016 02:36 PM, Adam D. Ruppe wrote:
> We had a migration plan and enough excitement to start working on the code

I don't think the plan is realistic. How can I tell you this without you getting mad at me? Apparently the only way to go is do as you say. -- Andrei

On 02.06.2016 15:48, Marc Schütz wrote:
>>
>
> No, I don't want to make string a range of anything, I want to provide
> an additional overload for joiner() that accepts a const(char)[], and
> returns a range of chars.

If strings are not ranges, returning a range of chars is inconsistent.

On Thursday, 2 June 2016 at 16:21:33 UTC, Andrei Alexandrescu wrote:
> On 06/02/2016 12:14 PM, Kagamin wrote:
>> 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.
>
> Walter and I have a unified view on this. Although I'd need to raise the issue that the primitive should be by!dchar, not byDchar. -- Andrei

The primitive is byUTF!dchar: http://dlang.org/phobos/std_utf#.byUTF. byDchar is just an alias.

On 06/02/2016 01:54 PM, Marc Schütz wrote:
> On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu wrote:
>> That's not going to work. A false impression created in this thread
>> has been that code points are useless
>
> They _are_ useless for almost anything you can do with strings. The only
> places where they should be used are std.uni and std.regex.
>
> Again: What is the justification for using code points, in your opinion?
> Which practical tasks are made possible (and work _correctly_) if you
> decode to code points, that don't already work with code units?

Pretty much everything. Consider s and s1 string variables with possibly different encodings (UTF8/UTF16).

* s.all!(c => c == 'ö') works only with autodecoding. It returns always false without.

* s.any!(c => c == 'ö') works only with autodecoding. It returns always false without.

* s.balancedParens('〈', '〉') works only with autodecoding.

* s.canFind('ö') works only with autodecoding. It returns always false without.

* s.commonPrefix(s1) works only if they both use the same encoding; otherwise it still compiles but silently produces an incorrect result.

* s.count('ö') works only with autodecoding. It returns always zero without.

* s.countUntil(s1) is really odd - without autodecoding, whether it works at all, and the result it returns, depends on both encodings. With autodecoding it always works and returns a number independent of the encodings.

* s.endsWith('ö') works only with autodecoding. It returns always false without.

* s.endsWith(s1) works only with autodecoding. Otherwise it compiles and runs but produces incorrect results if s and s1 have different encodings.

* s.find('ö') works only with autodecoding. It never finds it without.

* s.findAdjacent is a very interesting one. It works with autodecoding, but without it it just does odd things.

* s.findAmong(s1) is also interesting. It works only with autodecoding.

* s.findSkip(s1) works only if s and s1 have the same encoding. Otherwise it compiles and runs but produces incorrect results.

* s.findSplit(s1), s.findSplitAfter(s1), s.findSplitBefore(s1) work only if s and s1 have the same encoding. Otherwise they compile and run but produce incorrect results.

* s.minCount, s.maxCount are unlikely to be terribly useful but with autodecoding it consistently returns the extremum numeric code unit regardless of representation. Without, they just return encoding-dependent and meaningless numbers.

* s.minPos, s.maxPos follow a similar semantics.

* s.skipOver(s1) only works with autodecoding. Otherwise it compiles and runs but produces incorrect results if s and s1 have different encodings.

* s.startsWith('ö') works only with autodecoding. Otherwise it compiles and runs but produces incorrect results if s and s1 have different encodings.

* s.startsWith(s1) works only with autodecoding. Otherwise it compiles and runs but produces incorrect results if s and s1 have different encodings.

* s.until!(c => c == 'ö') works only with autodecoding. Otherwise, it will span the entire range.

===

The intent of autodecoding was to make std.algorithm work meaningfully with strings. As it's easy to see I just went through std.algorithm.searching alphabetically and found issues literally with every primitive in there. It's an easy exercise to go forth with the others.


Andrei