RFC: naming for FrontTransversal and Transversal ranges

[Michel Fortin]

On 2009-04-30 20:52:05 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

>>> (Last but not least, .NET has arrays and slices. D's slices that 
>>> actually have an array testis mesh real bad with .NET because in .NET 
>>> you can't have a disowned slice.)
>> 
>> I've been following the blog. I was surprised that Cristian didn't just 
>> make all D arrays .NET ArraySegments and be done with it, but there's 
>> probably issues I don't know about. I'd like to hear more on what 
>> exactly the issue was.
> 
> We discussed at length. Without being an expert in .NET, I can't tell 
> what the problem is, but I do know that if there was a simpler 
> solution, Cristi would have probably found it.

As I understand it, the issue is that the .NET API generally doesn't 
expect ArraySegments, but Array, so Cristi wants T[] to be an array, 
not an array segment, in order to make the API usable without having to 
duplicate ArraySegments into Arrays every time. I'm doubtful having a 
standard container type will help that much, as T[] (the slice) still 
won't be accepted by the .NET API and the programmer would simply have 
to always use the container.

That the .NET framework wants to use containers everywhere instead of 
slices is not a reason for D to bend to .NET concept of arrays and 
slices.

But...

That makes me think that perhaps my concept of "unique T[]" as the 
container (see my previous post) might be interesting. Cristi could 
make the compiler keep "unique T[]" in an Array and implicitly convert 
it to an ArraySegment as soon as it becomes non-unique. That would mean 
the .NET API could accept regular D dynamic arrays, as long as they're 
unique.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/