.NET on a string

[Cristian Vlasceanu]

>>
>> 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.

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.

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.

But there may be some yet unforseen side-effects (when dealing with generic 
code, for instance) that need to be further investigated before I push for 
this solution at full speed. If I find it to work suitably well I have no 
problem in making my own D 2.0 / .NET dialect...

Cheers,
Cristian