• Nicholas Wilson (10/20) Mar 21 2019 A plan of action on what to do about auto decoding is on the
• Seb (5/16) Mar 22 2019 Tried that already:
• Francesco Mecca (4/24) Mar 22 2019 What is gonna stop the community from repeating the Tango /
• Kagamin (4/6) Mar 22 2019 Those two were mutually exclusive, that's why they created total

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

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.

Seb <seb wilzba.ch> writes:

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

Francesco Mecca <me francescomecca.eu> writes:

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?

Kagamin <spam here.lot> writes:

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.