Removing AutoDecoding

[crazymonkyyy]

I think there's 2 ideas of what "removing auto decoding" will mean, and this will be a debate eventually

either verbose string iterators :"hello world".byAscii.spilt(' ')

or strings get their own overloads:

static assert(isRange!string==false);
"hello world".spilt(' '); //calls sys.string.spilt because sys.algorthim.spilt is required to check isRange

Please pick the first one

and then support indexing, and have overloads for all string usecases

There several valid ways to iterate on string:

1. ascii
2. unicode drawn character
3. unicode "codepoint"
4. codelike ascii where theres escapes
5. positional unicode where you handle Arabic writing backwards, endlines reset things

and then several ways to then use the indexes/data of those strings:

1. char litteral
2. char*
3. dchar as codepoints
4. null escaped c strings
5. char slices that are spilt by unicode rules

etc.

Strings are probaly the datastucture that has the most ways to iterate it by, so copy the aa's and have byPair, byValue and make some overloads for indexing that works with some c code; dont attempt to put some subset of that logic into a repeat of std.string duplicating logic and probaly failing most uses cases anyway

[LightBender]

Walter has already proposed using .byWChar and .byDChar so I see no reason why we should not extend that concept to the various cases we encounter. For example, .byCodepoint makes total sense to me. I would also like to see .asCString and .fromCString

One thing I would like to explicitly like to avoid is a proliferation of string-only overloads as it ends up becoming auto-decoding by a different means and is incredibly cumbersome to maintain.

[crazymonkyyy]

.asCString

I expect that we are talking about different things here
iterating a string making it into c string, either means making copies on every opSlice or in the case of splitter, injecting nulls on the sentinel chars

[atilaneves]

What does iterating a string etc. have to do with autodecoding?

[crazymonkyyy]

literally everything
ranges are a just a slice compared to a iterators pointer; its always been about iterating over data

[dukc]

I think there's 2 ideas of what "removing auto decoding" will mean, and this will be a debate eventually

either verbose string iterators :"hello world".byAscii.spilt(' ')

or strings get their own overloads:

static assert(isRange!string==false);
"hello world".spilt(' '); //calls sys.string.spilt because sys.algorthim.spilt is required to check isRange

Please pick the first one

If I pictured it correctly what's happening, it's closer to your first option. Strings are still defined as ranges of characters, not as a separate type.

One difference though: I think an array of characters will still be treated as a character range as-is, meaning you don't need to do that .byAscii call. The difference to V2 is the element type of the range. In V2 it's always DChar, in V3 it's going to be the element type of the array.