.NET on a string

[Steven Schveighoffer]

On Sun, 22 Mar 2009 01:31:28 -0400, Cristian Vlasceanu wrote:

>>>
>>> The idea of slices and arrays being distinct types does seem to have
>>> advantages. I've seen a couple of mentions of this lately, but has  
>>> there
>>> been a *rigorous* discussion?
>>
>> There has been.  But there are very good reasons to keep arrays and  
>> slices
>> the same type.  Even in C# and Java, a substring is the same type as a
>> string.  It allows iterative patterns such as:
>>
>> str = str[1..$];
>>
>
> I am afraid that there's a fallacy in your argument: substrings ARE  
> strings:
> 1) they are full copies of the characters in the given range, and 2) once
> the substring is created it goes its own merry way (i.e. it does not keep
> track of any relationship to the "original" string). Slices ARE NOT  
> arrays.
> Slices are more like "views" into the original array. It is like the
> difference between the icon and the saint / deity that it represents.

I thought one of the benefits of having immutable strings is that  
substrings were just pointers to slices of the original data in Java and  
.NET.  So every time I do a substring in Java and .NET, it creates a copy  
of the data?  That seems very wasteful, especially when the data is  
immutable...

Note I have no intimate knowledge of the inner workings of Java and .Net,  
I just went on what logically makes sense.

Your statement that slices are not arrays depends on your definition of  
slice and array.  To me, slices and arrays are identical.  Slices are  
simply a smaller set of the array.  It's like saying subsets are a  
different type than sets.  I suppose it depends on what language you  
learned about slices (for me it was D).

The only issue I see is the builtin append operation.  Everything else has  
a clean solution already.

> Another point that I have a hard time getting accross (even to the  
> language
> heavy-weights) is that just because it is easy to represent arrays and
> slices seemlessly IN THE PARTICULAR CASE OF THE DIGITAL MARS BACKEND it  
> does
> not mean it is going to work as smooth and seamless in other systems. The
> .NET backend that I am working on is the case in point. If instead of  
> using
> .NET built-in arrays I craft my own representation (to stay compatible  
> with
> the DMD's way of doing array and slices) then I give up interoperability
> with other languages -- and that would defeat the point of doing D on  
> .NET
> to begin with.

Fair enough, but I think restricting the design of D to cater to other  
back ends is probably not a huge driver for Walter.  It's not without  
precedent that people adapting languages to .NET have to introduce syntax  
changes to the language, no?  I'm thinking of C++.NET.

> Your proposed solution is interesting but implementation-specific. I am
> afraid that I cannot not use it with .NET (I just generate IL code,  
> which is
> more high-level than "ordinary" assembly code).
>
> I passed a proposal of my own to Walter and Andrei, and that is to have D
> coders explicitly state the intent of using a slice with the "ref"  
> keyword;
> "ref" is already a legal token in D (at least in 2.0) albeit it is only
> valid in the context of a parameter list, or foreach argument list. It is
> not legal to say "ref int j = i;" in a declaration, for example. But it  
> is a
> trivial change in the parser (I have implemented this change as a proof  
> of
> concept / language extension research) to allow ref (just for slices):  
> "ref
> int[] s = a[1..2];" other than in parameter and foreach arg lists.
>
> I think that "ref" makes sense, because slices, like I said, are
> conceptually views (or references) into the "true" arrays. This simple
> change would a) make D code more self-documenting, and it would give a  
> very
> powerful hint to the compiler. Also, the "ref" semantics is backwards
> compatbile with the exisiting cases where "ref" is allowed.

That is an interesting idea.  But I have a couple problems with it:

First, when I see ref int[] s, I think reference to an array, not this  
array references data from another array.
Second, your proposed default (not using ref) is to copy data everywhere,  
which is not good for performance.  Most of the time, arrays are passed  
without needing to "own" the data, so making copies everywhere you forgot  
to put ref would be hard to deal with.  It's also completely incompatible  
with existing code, which expects reference semantics without using ref.

-Steve