Right now, type casts (called conversions in the spec) always produce a single value. The idiomatic way to have checked casts would IMO be a two-value form, as this would be consistent with type assertions, channel receives, and map indexing, off the top of my head. End result would be something like:

  var x []byte
  y, ok := [32]byte(x)
  // ...

However, it feels like a relatively significant change to the language just for a niche use. Even the ability to cast from []T to [N]T or *[N]T is actually fairly new (Go 1.20 and 1.17, respectively). I don't think it's that hard to check the length before casting, though a checked cast would be convenient since you wouldn't have to repeat the length between the check and the cast.

▲ XorNot 5 hours ago | parent [-]

But it would be a subvariant of a much more common pattern in code - destructuring which is quite noisy now but could just be:

  a, b, rest := strings.Split(somestr, "/")

Which would be conventional for the whole thing, and the check would be for an empty type after rest.

I usually wind up using something like the samber/lo library to reduce the noise here. You wind up doing this all the time.

	▲	kbolino 5 hours ago \| parent [-]
		I must disagree. Destructuring is nifty, but it is almost completely unrelated. The second value in any of the builtin two-value assignment forms is invariant on the type or size of RHS; it's always a boolean, and its meaning relates to the "kind" of RHS, not the exact type: `msg, ok := <-ch // ok means "channel ch is not closed" val, ok := m[key] // ok means "map m contains key" dyn, ok := i.(T) // ok means "interface i's dynamic type is T or implements T"` This new operation would be similar: `arr, ok := [N]T(s) // ok means "slice s has len(s) == N"` For all of these cases, ok being true indicates that the other value is safe to use.