5 ms·
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 pilin
by premium-concern 10y ago
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.
- pjmlp 10y agoBecause of backwards compatibility.
- premium-concern 10y agoHow is that impacted by a faster implementation technique? Are you arguing that some people rely on ArraySegment being slow?
- pjmlp 10y agoNo, 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.
- algorithmsRcool 10y agoI 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.