Hacker News Reader

Comment by recursive | Hacker News Reader

I'm curious how array slicing is any different from ArraySegment<T>, which is very old.

ArraySegment<T> is just a array reference with range delimiters. Slice/Span gives you a low overhead, type safe window into a block of memory that can be reinterpreted without allocating new memory. It's implementation involves some IL level pointer hacks to keep it fast.

Joe Duffy's first implmentation of it is here: https://github.com/joeduffy/slice.net

The more recent work for CoreFX is here: https://github.com/dotnet/corefxlab/tree/master/src/System.S...

So instead of improving the implementation of ArraySegment they just add yet another way of doing it?

This is of course expected for languages which keep piling up stuff but still disappointing.

Because of backwards compatibility.

How is that impacted by a faster implementation technique?

Are you arguing that some people rely on ArraySegment being slow?

No, it isn't compatible with any of the existing APIs that accept array or strings.

So making it compatible would probably require breaking its semantics.

I think Span really goes way beyond what ArraySegment was intended to do. ArraySegment was just a way of wrapping the very common 3 parameters (Array, offset, length) used in almost any buffer copy operation into a single object.

Span/slice was a much more ambitious type that not only provided fast array segment like access, but also introduced a way to provide typed views into byte[] without the cost of casting or copying memory.

Span<T> is low level enough that they considered calling it Array<T> but decided against it to avoid even more confusion.

If you want to see an example of a API failure it is with System.Tuple<>. That type is effectively being deprecated when ValueTuple comes into the BCL with proper compiler support.

Reply on news.ycombinator.com