On 06/01/2016 04:28 PM, Timon Gehr wrote:
> On 01.06.2016 17:30, Andrei Alexandrescu wrote:
>> On 06/01/2016 11:24 AM, Jonathan M Davis via Digitalmars-d wrote:
>>> It seems more like RCString is an optimization for certain types of
>>> programs than what you'd want to use by default.
>>
>> You'll always want to use it. The small string optimization will make it
>> compelling for all applications. -- Andrei
>
>
> - Why is it dependent on the allocation strategy or on the type of the
> data?

Not getting this.

> - It seems to be a pessimization if I'm taking a lot of small slices.

I agree cases can be created in which straight arrays do sometimes better. They are rare and far between - for strings, the small string optimization is to live by.

> - It is undesirable if I later want to reference-compare those slices.

Arrays will still be usable.


Andrei

On 01.06.2016 22:43, Andrei Alexandrescu wrote:
> On 06/01/2016 04:28 PM, Timon Gehr wrote:
>> On 01.06.2016 17:30, Andrei Alexandrescu wrote:
>>> On 06/01/2016 11:24 AM, Jonathan M Davis via Digitalmars-d wrote:
>>>> It seems more like RCString is an optimization for certain types of
>>>> programs than what you'd want to use by default.
>>>
>>> You'll always want to use it. The small string optimization will make it
>>> compelling for all applications. -- Andrei
>>
>>
>> - Why is it dependent on the allocation strategy or on the type of the
>> data?
>
> Not getting this.
> ...

The small string optimization also works for GC-allocated strings. Why do I always want to use RCString instead of the corresponding GCString?
(Also, the same approach can be applied to other arrays with value semantics.)

On 06/01/2016 05:03 PM, Timon Gehr wrote:
> The small string optimization also works for GC-allocated strings. Why
> do I always want to use RCString instead of the corresponding GCString?
> (Also, the same approach can be applied to other arrays with value
> semantics.)

Point taken, thanks. Mine was that you can't (reasonably) use the SSO if you commit to represent strings as bare slices. -- Andrei

On Wednesday, 1 June 2016 at 11:42:06 UTC, Seb wrote:
> On Wednesday, 1 June 2016 at 02:39:55 UTC, Nick Sabalausky wrote:
>> On 05/31/2016 09:36 PM, Adam D. Ruppe wrote:
>>>
>>> version(string_migration)
>>> deprecated void popFront(T)(ref T t) if(isSomeString!T) {
>>>    static assert(0, "this is crap, fix your code.");
>>> }
>>> else
>>> deprecated("use -versionstring_migration to fix your buggy code, would
>>> you like to know more?")
>>> /* existing popFront here */
>>>
>>
>> I vote we use Adam's exact verbiage, too! :)
>>
>>>
>>> D USERS **WANT** BREAKING CHANGES THAT INCREASE OVERALL CODE QUALITY
>>> WITH A SIMPLE MIGRATION PATH!!!!!!!!!!!!!!!!!!!!
>>>
>>
>> Yes. This. If I wanted an endless bucket of baggage, I'd have stuck with C++.
>>
>>> 3) A wee bit longer, we exterminate all this autodecoding crap and enjoy
>>> Phobos being a smaller, more efficient library.
>>>
>>
>> Yay! Profit!
>
>
> How about a poll?
>
> http://www.polljunkie.com/poll/ftmibx/remove-auto-decoding-in-d
>
> Results are shown after casting a vote or here:
> http://www.polljunkie.com/poll/aqzbwg/remove-auto-decoding-in-d/view

Just FYI after a short period of ten hours we got the following 45 responses:

Yes, with fire! (hobby user)                                          77% (35)
Yeah remove that special behavior (professional user)                 35% (16)
Wait that is what auto decoding is? wah ugh...                        8%  (4)
I don't always decode codeunits, but when I do I use byDChar already  6%  (3)

On Wednesday, 1 June 2016 at 02:36:15 UTC, Walter Bright wrote:
> PRs please!

https://github.com/dlang/phobos/pull/4384

You'll notice it is closed.

Now, that one wasn't meant to be merged anyway, but Andrei seems to have zero interest in actually accepting the change. That doesn't encourage further work.

On 6/1/2016 8:51 PM, Adam D. Ruppe wrote:
> On Wednesday, 1 June 2016 at 02:36:15 UTC, Walter Bright wrote:
>> PRs please!
>
> https://github.com/dlang/phobos/pull/4384
>
> You'll notice it is closed.
>
> Now, that one wasn't meant to be merged anyway, but Andrei seems to have zero
> interest in actually accepting the change. That doesn't encourage further work.

Andrei is in favor of fixing Phobos so it does not depend on autodecode. He is, however, rightfully concerned about the extent of breakage that would happen if autocode were removed. So am I.

Interestingly, when I tried to remove autodecoding from path/file code a couple years ago, I received quite a bit of resistance. It seems there's been a tectonic shift in opinion on autodecode.

What I'd like to see, that we all agree on, is progress in removing autodecode reliance from Phobos. Let's see what it takes.

On Thursday, 2 June 2016 at 00:14:30 UTC, Seb wrote:

> Just FYI after a short period of ten hours we got the following 45 responses:
>
> Yes, with fire! (hobby user)
>     77% (35)
> Yeah remove that special behavior (professional user)
>     35% (16)
> Wait that is what auto decoding is? wah ugh...
>     8%  (4)
> I don't always decode codeunits, but when I do I use byDChar already  6%  (3)

You failed to mention that there were additional answers:

Auto-decoding is great!
0% (0)
No, please don't break my code.
0% (0)

I think those zeroes are actually the most important part of the results. :)

On Wednesday, June 01, 2016 21:42:49 Walter Bright via Digitalmars-d wrote:
> On 6/1/2016 8:51 PM, Adam D. Ruppe wrote:
> > On Wednesday, 1 June 2016 at 02:36:15 UTC, Walter Bright wrote:
> >> PRs please!
> >
> > https://github.com/dlang/phobos/pull/4384
> >
> > You'll notice it is closed.
> >
> > Now, that one wasn't meant to be merged anyway, but Andrei seems to have zero interest in actually accepting the change. That doesn't encourage further work.
> Andrei is in favor of fixing Phobos so it does not depend on autodecode. He is, however, rightfully concerned about the extent of breakage that would happen if autocode were removed. So am I.

Just pulling the trigger is far too big a breaking change, and I think that a number of us who are strongly in favor of getting rid of auto-decoding agree with you on that. At some point, we may very well need to decide between breaking code and permanently carrying this technical debt, but the first thing to do is to work towards mitigating the breaking changes as much as possible. Then at least, if we do break code, the impact is much lower.

> Interestingly, when I tried to remove autodecoding from path/file code a couple years ago, I received quite a bit of resistance. It seems there's been a tectonic shift in opinion on autodecode.

A number of us very much liked the idea at first, but part of the problem was that a lot of us didn't understand Unicode well enough at the time. And as we've come to better understand it, we've seen how poor a design decision it is to auto-decode. Also, the number of questions and complaints that we've had to field over time with regards to auto-decoding has helped highlight how problematic it is from a usability standpoint. So, most of us who didn't understand well enough up front have learned better.

> What I'd like to see, that we all agree on, is progress in removing autodecode reliance from Phobos. Let's see what it takes.

Agreed.

- Jonathan M Davis

On Thursday, 2 June 2016 at 06:53:49 UTC, poliklosio wrote:
> On Thursday, 2 June 2016 at 00:14:30 UTC, Seb wrote:
>
>> Just FYI after a short period of ten hours we got the following 45 responses:
>>
>> Yes, with fire! (hobby user)
>>     77% (35)
>> Yeah remove that special behavior (professional user)
>>     35% (16)
>> Wait that is what auto decoding is? wah ugh...
>>     8%  (4)
>> I don't always decode codeunits, but when I do I use byDChar already  6%  (3)
>
> You failed to mention that there were additional answers:
>
> Auto-decoding is great!
> 0% (0)
> No, please don't break my code.
> 0% (0)
>
> I think those zeroes are actually the most important part of the results. :)

It has been noted many times that forum users are a small part of the D userbase, likely the ones who are the most interested in evolving the language and thus biased towards changes.  As a forum user myself, I'm in that group too and agree with Walter that D programmers should be guided by Phobos to explicitly declare what level of decoding they want, but this poll may not be representative of the wider userbase.

We'll likely only find out what they think once we're a couple dmd releases into these changes, as Walter found when he submitted PRs for file/path code sometime back.

On Wednesday, June 01, 2016 11:30:02 Andrei Alexandrescu via Digitalmars-d wrote:
> On 06/01/2016 11:24 AM, Jonathan M Davis via Digitalmars-d wrote:
> > It seems more like RCString is an optimization for certain types of programs than what you'd want to use by default.
>
> You'll always want to use it. The small string optimization will make it compelling for all applications. -- Andrei

Well, ref-counting vs GC aside, optimizations like that are actually something that can clearly make a user-defined type for strings worth using over naked arrays of code units, whereas it's far less clear that having a user-defined type for strings because of Unicode-related issues actually buys us much.

- Jonathan M Davis