On Wednesday, 1 June 2016 at 01:36:43 UTC, Adam D. Ruppe wrote:
> On Wednesday, 1 June 2016 at 00:46:04 UTC, Walter Bright wrote:
>> It is not practical to just delete or deprecate autodecode
>
> Yes, it is.
>
> We need to stop holding on to the mistakes of the past. 9 of 10 dentists agree that autodecoding is a mistake. Not just WAS a mistake, IS a mistake. It has ongoing cost. If we don't fix our attitude about these problems, we are going to turn into that very demon we despise, yea, even the next C++!
>

Please, just remove auto-decoding, any way you want. I only ever used it once or twice voluntarily. It's a special case that must go.
Maybe with a flag like for -vtls.

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

On 05/31/2016 08:46 PM, Walter Bright wrote:
> It is not practical to just delete or deprecate autodecode - it is too
> embedded into things. What we can do, however, is stop using it
> ourselves and stop relying on it in the documentation, much like [] is
> eschewed in favor of std::vector in C++.
>
> The way to deal with it is to replace reliance on autodecode with
> .byDchar (.byDchar has a bonus of not throwing an exception on invalid
> UTF, but using the replacement dchar instead.)
>
> To that end, and this will be an incremental process:
>
> 1. Temporarily break autodecode such that using it will cause a compile
> error. Then, see what breaks in Phobos and fix those to use .byDchar
>
> 2. Change examples in the documentation and the Phobos examples to use
> .byDchar
>
> 3. Best practices should use .byDchar, .byWchar, .byChar, .byCodeUnit
> when dealing with ranges/arrays of characters to make it clear what is
> happening.

(Shouldn't those be by!dchar, by!wchar, by!char? byCodeUnit and byCodePoint stay as they are.)

4. Rally behind RCStr as the preferred string type of the D language. RCStr manages its own memory, is fast, and has the right interface (i.e. offers several views for iteration without an implicit one, doesn't throw on invalid code points, etc).

This is the key component. We get rid of GC-backed strings, which is part of the crucial goal for D we need to achieve, and reap the benefit of a better design as a perk. Breaking existing code does not have the right benefit for the cost.

Let's keep the eyes on the ball, folks. We want to rid D of the GC. That's the prize.


Andrei

On Wednesday, 1 June 2016 at 12:14:06 UTC, Andrei Alexandrescu wrote:
> On 05/31/2016 08:46 PM, Walter Bright wrote:
>
> (Shouldn't those be by!dchar, by!wchar, by!char? byCodeUnit and byCodePoint stay as they are.)
>
> 4. Rally behind RCStr as the preferred string type of the D language. RCStr manages its own memory, is fast, and has the right interface (i.e. offers several views for iteration without an implicit one, doesn't throw on invalid code points, etc).
>
> This is the key component. We get rid of GC-backed strings, which is part of the crucial goal for D we need to achieve, and reap the benefit of a better design as a perk. Breaking existing code does not have the right benefit for the cost.
>
> Let's keep the eyes on the ball, folks. We want to rid D of the GC. That's the prize.
>
>
> Andrei

How would the transition look like? How would it affect existing code, like e.g.  `countUntil`, `.length` etc.?

On Wednesday, 1 June 2016 at 02:36:15 UTC, Walter Bright wrote:
> On 5/31/2016 6:36 PM, Adam D. Ruppe wrote:
>> Our preliminary investigation found about 130 places in Phobos that need to be
>> changed. That's not hard to fix!
>
> PRs please!

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

On Wednesday, 1 June 2016 at 02:28:04 UTC, Jonathan M Davis wrote:
> The other critical thing is to make sure that Phobos in general works with byDChar, byCodeUnit, etc. For instance, pretty much as soon as I started trying to use byCodeUnit instead of naked strings, I ran into this:
>
> https://issues.dlang.org/show_bug.cgi?id=15800

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

On Wednesday, 1 June 2016 at 01:36:43 UTC, 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 */

version(autodecode_migration)
deprecated("autodecode attempted, use byDchar instead")
alias popFront=_d_popFront;
else
alias popFront=_d_popFront;

void _d_popFront(T)(ref T t) if(isSomeString!T) {
/* existing popFront here */
}

The migration branch should compile and work or template constraints will silently fail. Then deprecation messages can be grepped. That said does compiler print deprecation messages triggered inside template constraints?

On Wednesday, June 01, 2016 08:14:06 Andrei Alexandrescu via Digitalmars-d wrote:
> 4. Rally behind RCStr as the preferred string type of the D language. RCStr manages its own memory, is fast, and has the right interface (i.e. offers several views for iteration without an implicit one, doesn't throw on invalid code points, etc).
>
> This is the key component. We get rid of GC-backed strings, which is part of the crucial goal for D we need to achieve, and reap the benefit of a better design as a perk. Breaking existing code does not have the right benefit for the cost.
>
> Let's keep the eyes on the ball, folks. We want to rid D of the GC. That's the prize.

Since when has it been the goal to get rid of GC-allocated strings? We definitely want an alternative to GC-allocated strings for code that can't afford to use the GC, but auto-decoding issues aside, why would I want to use RCString instead of string if the GC isn't a problem for my program? Walter pointed out at dconf that using a GC is often faster than reference counting; it's just that it can incur a large cost at once when a collection is run, whereas the cost of ref-counting is amortized across the time that the program is running.

I expect that RCString will be very important for us going forward, but I don't see much reason to use it as the default string type in code over just using string except for the fact that we have the auto-decoding mess to deal with. It seems more like RCString is an optimization for certain types of programs than what you'd want to use by default.

- Jonathan M Davis

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

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?

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

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