.NET Core 2.1 was announced, with emphasis on using Span<T> instead of classic String class all around the framework. For people not familiar with C#, Span<T> is similar to a D array slice.

https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/

On Friday, 20 April 2018 at 16:33:44 UTC, rumbu wrote:
> .NET Core 2.1 was announced, with emphasis on using Span<T> instead of classic String class all around the framework. For people not familiar with C#, Span<T> is similar to a D array slice.
>
> https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/

And we’re trying to move towards a string library type and away from raw slices :)

On 4/20/18 8:27 PM, Jack Stouffer wrote:
> On Friday, 20 April 2018 at 16:33:44 UTC, rumbu wrote:
>> .NET Core 2.1 was announced, with emphasis on using Span<T> instead of classic String class all around the framework. For people not familiar with C#, Span<T> is similar to a D array slice.
>>
>> https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/ 
>>
> 
> And we’re trying to move towards a string library type and away from raw slices :)

Since when?

-Steve

On Saturday, 21 April 2018 at 16:08:13 UTC, Steven Schveighoffer wrote:
> On 4/20/18 8:27 PM, Jack Stouffer wrote:
>> On Friday, 20 April 2018 at 16:33:44 UTC, rumbu wrote:
>>> .NET Core 2.1 was announced, with emphasis on using Span<T> instead of classic String class all around the framework. For people not familiar with C#, Span<T> is similar to a D array slice.
>>>
>>> https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/
>>>
>> 
>> And we’re trying to move towards a string library type and away from raw slices :)
>
> Since when?
>
> -Steve

At least 2 1/2 years:

https://forum.dlang.org/thread/56B1224A.7050309@erdani.com

On 4/21/18 2:37 PM, Seb wrote:
> On Saturday, 21 April 2018 at 16:08:13 UTC, Steven Schveighoffer wrote:
>> On 4/20/18 8:27 PM, Jack Stouffer wrote:
>>> On Friday, 20 April 2018 at 16:33:44 UTC, rumbu wrote:
>>>> .NET Core 2.1 was announced, with emphasis on using Span<T> instead of classic String class all around the framework. For people not familiar with C#, Span<T> is similar to a D array slice.
>>>>
>>>> https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/ 
>>>>
>>>>
>>>
>>> And we’re trying to move towards a string library type and away from raw slices :)
>>
>> Since when?
>>
> 
> At least 2 1/2 years:
> 
> https://forum.dlang.org/thread/56B1224A.7050309@erdani.com

An RCString could have slicing just like C#.

And it doesn't prevent "raw slicing" with char arrays.

FWIW, I support having a string library type and have been advocating for it for years (I'd love to have my char arrays back as arrays of chars). But it MUST support slicing to pass muster in D.

-Steve

On Saturday, 21 April 2018 at 16:08:13 UTC, Steven Schveighoffer wrote:
> Since when?
>
> -Steve

Since Andrei came up with the RCStr concept. Even a non-RC String type would still solve our auto decoding problem while also allowing us to do SSO.

On Saturday, 21 April 2018 at 19:15:58 UTC, Steven Schveighoffer wrote:
> An RCString could have slicing just like C#.
>
> And it doesn't prevent "raw slicing" with char arrays.
>
> FWIW, I support having a string library type and have been advocating for it for years (I'd love to have my char arrays back as arrays of chars). But it MUST support slicing to pass muster in D.

A slice of a String could also return a String, and have some property raw or toArray to get the underlying slice.

On 4/21/18 4:31 PM, Jack Stouffer wrote:
> On Saturday, 21 April 2018 at 16:08:13 UTC, Steven Schveighoffer wrote:
>> Since when?
>>
> Since Andrei came up with the RCStr concept. Even a non-RC String type would still solve our auto decoding problem while also allowing us to do SSO.

Rereading your post, I misunderstood. I thought you implied that we would be getting rid of slicing from strings, but that's not what you meant.

I'm all for a string type and auto-decoding, so we can get rid of auto-decoding for char arrays.

-Steve

On Saturday, 21 April 2018 at 20:54:32 UTC, Steven Schveighoffer wrote:
> I'm all for a string type and auto-decoding, so we can get rid of auto-decoding for char arrays.

I've floated the idea of having the String type not be a range in order to solve this problem once and for all. In order to get a range from a String, you'd have to call toCodeUnits, toCodePoints, or toGraphemes, which would all be range returning member functions. That way, the user is in charge of the iteration every time, and there's no "magic" involved.

I might whip up a proof-of-concept of a String (without RC but with SSO) later when I have free time. It'd be useful in some of my projects.