Assign an array to sentinel array

[Araminosian]

Zig Version

0.10.1

Steps to Reproduce and Observed Behavior

var array: [2]u8 = .{ 1, 2 };
var sentinel_array: [2:0]u8 = array;

error: expected type '[2:0]u8', found '[2]u8'

Expected Behavior

There is no reason to prohibit this operation. That is just a copy.

[rohlem]

I agree. If the implicit conversion is somehow deemed controversial (not sure why), at least allowing it explicitly via @as would be nice - in status-quo you need a utility function to implement it.
EDIT: Actually, I'm not a fan of @as allowing a coercion that isn't allowed implicitly.
(IIRC in status-quo, the only difference is that the length of an implicit coercion sequence is limited, which can be extended by @as.)

Another alternative would be a dedicated @sentinelCast (with deduced result type) for maximum explicitness.

[matu3ba]

There is no reason to prohibit this operation. That is just a copy.

Consider

var array: [100_000]u8 = .{ 1, 2 };
var sentinel_array: [100_000:0]u8 = array;

1. It's not evident from = array, that several copies, most likely a loop is used in the assembly with potential significant time for execution.
2. I dont see the significant advantage over @memcpy
3. Having multiple occurences of

var array: [2]u8 = .{ 1, 2 };
var sentinel_array: [2:0]u8 = array;

which are not as helper functions smells like a bad design. Or do you have concrete code examples, where an inline function with comptime to create the zero-terminated memory structure[s] of a given array size is not possible?

[InKryption]

It's not evident from = array, that several copies, most likely a loop is used in the assembly with potential significant time for execution.

This is already the case for non-sentinel copies of arrays. This would be an argument against status quo as well.

[matu3ba]

This is already the case for non-sentinel copies of arrays. This would be an argument against status quo as well.

For comptime-assignments, yes. For runtime-assignments, I think this is not correct.
Assigning slices certainly works, because its a pointer + len to the bytes, but not arrays themself.

Or do you have a brief counter-example?

Not a fan, but consistent.

Reason why I dislike the current behavior:

test {
    var x: u8 = 100;
    var a: [1_000]u8 = .{x} ** 1_000;
    var b: [1_000]u8 = undefined;

    // a pile of code

    b = a; // spot the performance issue

    // a pile of code
}

[mlugg]

For comptime-assignments, yes. For runtime-assignments, I think this is not correct. Assigning slices certainly works, because its a pointer + len to the bytes, but not arrays themself.

Or do you have a brief counter-example?

I mean... just try it? You can totally copy arrays, they're nothing special:

test {
    var x: u8 = 100;
    var a: [1000]u8 = .{x} ** 1000;
    var b: [1000]u8 = a;
    _ = b;
}

All 1 tests passed.

[kfird214]

I think array copies should be explicit anyway.
@mlugg example should not work

test {
    var x: u8 = 100;
    var a: [1000]u8 = .{x} ** 1000;
    var b: [1000]u8 = a;
    _ = b;
}

code on compiler explorer
The compiler will use memset under the hood.
I would consider that a hidden control flow

fun:
  push rax
  mov edi, offset example.a
  mov edx, 1000
  mov esi, 100
  call memset@PLT
  mov edi, offset example.b
  mov edx, 1000
  mov esi, 100
  call memset@PLT
  mov edi, offset example.a
  mov esi, offset example.b
  pop rax
  jmp f@PLT