• rumbu (5/5) Apr 20 2018 .NET Core 2.1 was announced, with emphasis on using Span
• Jack Stouffer (3/8) Apr 20 2018 And we’re trying to move towards a string library type and away
• Steven Schveighoffer (3/13) Apr 21 2018 Since when?
• Seb (4/18) Apr 21 2018 At least 2 1/2 years:
• Steven Schveighoffer (7/27) Apr 21 2018 An RCString could have slicing just like C#.
• Jack Stouffer (4/10) Apr 21 2018 A slice of a String could also return a String, and have some
• Jack Stouffer (5/7) Apr 21 2018 Since Andrei came up with the RCStr concept. Even a non-RC String
• Steven Schveighoffer (6/12) Apr 21 2018 Rereading your post, I misunderstood. I thought you implied that we
• Jack Stouffer (11/13) Apr 21 2018 I've floated the idea of having the String type not be a range in

rumbu <rumbu rumbu.ro> writes:

.NET Core 2.1 was announced, with emphasis on using Span<T> 
instead of classic String class all around the framework. For 

slice.

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

Jack Stouffer <jack jackstouffer.com> writes:

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 

 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 :)

Steven Schveighoffer <schveiguy yahoo.com> writes:

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 


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

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

Since when?

-Steve

Seb <seb wilzba.ch> writes:

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 

 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

Steven Schveighoffer <schveiguy yahoo.com> writes:

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 


 https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improveme
ts-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



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

Jack Stouffer <jack jackstouffer.com> writes:

On Saturday, 21 April 2018 at 19:15:58 UTC, Steven Schveighoffer 
wrote:


 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.

Jack Stouffer <jack jackstouffer.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Jack Stouffer <jack jackstouffer.com> writes:

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.