https://swift.org/blog/utf8-string/

Choice paragraph:

>For example, source code (like most content) is encoded as UTF-8, so SourceKit represents and communicates positions in source code as offsets into a UTF-8 buffer. In Swift 4.2, writing an efficient client of a UTF-8 based service required maintaining a bidirectional index-mapping table from UTF-8 offsets to UTF-16 indices. Even forming a Swift 4.2 string from UTF-8 content involves transcoding the content to UTF-16, which can expensive. For example, SwiftNIO saw a 20% speed improvement when serving up the homepage of swift.org by just upgrading to Swift 5, due to skipping this transcoding.

A plan of action on what to do about auto decoding is on the agenda for the dconf AGM, but I figured there is no harm starting the discussion now.

My current vague idea is to add a version(Phobos_NoAutodecode) that changes the default behaviour, as opt in and then deprecate the use of the decoding .front/.popFront and require .by[W|D]char for when decoding is actually desired.

Anyway more/better/less vaguely defined ideas welcome.

On Friday, 22 March 2019 at 03:49:20 UTC, Nicholas Wilson wrote:
> https://swift.org/blog/utf8-string/
>
> Choice paragraph:
>
>>[...]
>
> A plan of action on what to do about auto decoding is on the agenda for the dconf AGM, but I figured there is no harm starting the discussion now.
>
> My current vague idea is to add a version(Phobos_NoAutodecode) that changes the default behaviour, as opt in and then deprecate the use of the decoding .front/.popFront and require .by[W|D]char for when decoding is actually desired.

Tried that already:

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

> Anyway more/better/less vaguely defined ideas welcome.

Write a new standard library. Some vague ideas are here:

https://github.com/wilzbach/dts

On Friday, 22 March 2019 at 07:36:48 UTC, Seb wrote:
> On Friday, 22 March 2019 at 03:49:20 UTC, Nicholas Wilson wrote:
>> https://swift.org/blog/utf8-string/
>>
>> Choice paragraph:
>>
>>>[...]
>>
>> A plan of action on what to do about auto decoding is on the agenda for the dconf AGM, but I figured there is no harm starting the discussion now.
>>
>> My current vague idea is to add a version(Phobos_NoAutodecode) that changes the default behaviour, as opt in and then deprecate the use of the decoding .front/.popFront and require .by[W|D]char for when decoding is actually desired.
>
> Tried that already:
>
> https://github.com/dlang/phobos/pull/5513

Can you explain why this PR failed? What are the counterarguments?
>
>> Anyway more/better/less vaguely defined ideas welcome.
>
> Write a new standard library. Some vague ideas are here:
>
> https://github.com/wilzbach/dts

What is gonna stop the community from repeating the Tango / Phobos fiasco?

On Friday, 22 March 2019 at 10:59:31 UTC, Francesco Mecca wrote:
> What is gonna stop the community from repeating the Tango / Phobos fiasco?

Those two were mutually exclusive, that's why they created total split. Dub packages usually don't do it this way, they are just dependencies.