Steven Schveighoffer wrote:
On Thu, 18 Feb 2010 20:47:16 -0500, Denis Koroskin <2kor...@gmail.com>
wrote:
On Fri, 19 Feb 2010 00:46:05 +0300, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
That would be bad, T[] is implicitly casted from T[N]. Consider
that you could easily escape stack data using this. In other words,
the type system would allow the assignment without the dup.
-Steve
I don't think so. First of all, it is consistent with current behavior:
int[] foo()
{
int[3] staticArray = [0, 1, 2];
int[] dynamicArray = staticArray;
return dynamicArray;
}
Here is the case I'd say looks bad to me:
int[] foo()
{
int[] dynamicArray = [0, 1, 2];
return dynamicArray;
}
If [0, 1, 2] is a static array, then it escapes its scope and corruption
ensues. The implicit static array is the problem, not the assigning of
a dynamic array from a static array. The literal doesn't look like it's
a static array.
SafeD will take care of it. As the compiler has to support SafeD anyway,
the same mechanisms can be used to create warnings or even errors in
normal D code.
Don wants to make array literals immutable; that means you couldn't just
assign them to int[] anyway. In both cases, you'd have to use .dup to
use them as normal, mutable arrays.
Array literals being static arrays would be very handy in other places.
Wouldn't it be nice if you could just use them for small fixed size
vectors (wasn't that one of the reasons to make static arrays value
types)? Then you could write assert([1, 2] + [3, 4] == [4, 6]). No silly
struct vector "classes" needed.
Second, it's very useful to prevent unnecessary heap allocations.
This is already available by using a static array explicitly. The
Static arrays still suck a bit, although making them value types
improved the situation.
Inside functions, this still allocates an array on the heap and copies
it into the static array:
int[2] array = [1, 2];
I don't quite know why it can't just behaves as if "array" was declared
on module level (or as, um, the other "static").
question is, what should be the default? I think making it immutable
and non-static is the right choice because it can always escape scope,
and does not require an allocation. From there you can do either a
static array if you know it won't escape scope, or a dynamic array (via
dup) if you need to modify it and it will escape scope.
How would you "do" a static array from an immutable array?
As I understood, immutable array literals would still require heap
allocations sometimes. Because even runtime dependent values can be
immutable.
Actually, if array literals only worked for compile time values, array
literals could be both immutable and static arrays allocated in the data
segment.
I would prefer static arrays not to cast to dynamic ones implicitly,
but using opSlice syntax instead:
int[] arr = [0, 1, 2]; // error
int[] arr = [0, 1, 2][]; // fine, use on your own risk
I agree. I wonder how static arrays will be handled in SafeD. Maybe just
disallow using them as normal arrays? Require an explicit .dup? Anyway,
it will be safe.
This is just an annoyance error. What will happen is people will
constantly just use the brackets to shut up the compiler without
thinking about what it really means.
Not really an argument, when array literals will be immutable, you could
as well say:
//the cast is only there to shut up the stupid dmd!
int[] arr = cast(int[])([0, 1, 2]);
-Steve
