Extend slice length on the left

Firstly, to answer your question, no it's not possible to use negative indices or access that data except by keeping a copy of the original slice.

However this is an interesting question, as there is an inconsistency here that you've pointed out, which is probably more what you're asking about. If you start with a slice as here:

a := []int{2, 3, 5, 7, 11, 13}
fmt.Println(a,len(a),cap(a)) 

[2 3 5 7 11 13] 6 6

And take a slice of just the middle

b := a[1:2]
fmt.Println(b,len(b),cap(b)) 

[3] 1 5

You are not allowed to access indexes in the original data past that slice len, as you'd expect:

fmt.Println(b[3]) 

panic: runtime error: index out of range

You are not allowed to reslice to include that data again from before the start index:

d := b[-1:]

invalid slice index -1 (index must be non-negative)

But you are allowed to reslice to include that data again after the len up to cap, which is a little odd:

// This is beyond the length of b, you can't index those, 
// but you can access them by reslicing 
c := b[:5]

[3 5 7 11 13] 5 5

This is a bit inconsistent as most other operations on slice data are bounded by the offset into the data and the len, not the cap and original data length. However, this is explicitly stated in the spec and is probably just an artefact of how slices represent the view onto the original array rather than an intentional design decision to provide access to that data. It might be nice if you could get back to the original storage, since it is still in memory, but it seems you can only see the end of the array up to cap, not the start after you have sliced once. From the spec about limits on slicing indexes:

For arrays or strings, the indices are in range if 0 <= low <= high <= len(a), otherwise they are out of range. For slices, the upper index bound is the slice capacity cap(a) rather than the length. A constant index must be non-negative and representable by a value of type int; for arrays or constant strings, constant indices must also be in range. If both indices are constant, they must satisfy low <= high. If the indices are out of range at run time, a run-time panic occurs.

It would probably be better to be safe and use the original slice to create different views on the data, rather than relying on this behaviour.

When you make a new slice from the 2nd index in the underlying array, like you do with s = s[1:4], then you have lost the reference to the first element in the underlying array.

And since the slice operator s[i:j] requires i >= 0, you can no longer access the first element in the original array by further slicing your existing slice.

You could keep the original array around, however:

func main() {
    a := [...]int{2, 3, 5, 7, 11, 13}

    s := a[1:4]
    fmt.Println(s)      // [3 5 7]
    fmt.Println(len(s)) // 3

    s = s[:4]
    fmt.Println(s)      // [3 5 7 11]
    fmt.Println(len(s)) // 4

    s = a[:]
    fmt.Println(s) // [2 3 5 7 11 13]
}

Let's look at the type definition of the slice header from the Go source code.

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

The name of the "array" field is slightly misleading, as it's not a reference to an array type like you would get from a statement a := [10]int{}; p := &a, but rather a pointer to a specific element within an array (the element which is the first element of the slice).

Now, if you look at the unsafe package documentation, you might notice that incrementing an unsafe.Pointer into memory that is not allocated is an invalid operation:

It is valid both to add and to subtract offsets from a pointer in this way. It is also valid to use &^ to round pointers, usually for alignment. In all cases, the result must continue to point into the original allocated object.

Unlike in C, it is not valid to advance a pointer just beyond the end of its original allocation...

Despite this, there is no guarantee that this will actually be checked at runtime, so it's often perfectly possible and trivial to end up with an unsafe.Pointer that points to unallocated memory, as in the following example:

package main

import (
    "fmt"
    "unsafe"
)

func main() {

    a := [10]int{}
    for i := range a {
        a[i] = i + 1
    }
    fmt.Printf("a: %v\n", a)

    s := a[2:5]

    p := unsafe.Pointer(&s[0])
    fmt.Printf("p initially points at the 3rd element of a...\n")

    // Let's break the rules!
    for i := 0; i < 15; i++ {
        if i == len(s) {
            fmt.Printf("We've hit the end of slice s, but there is still memory allocated past this in the backing array a...\n")
        }
        if i == cap(s) {
            fmt.Printf("We're in invalid/undefined territory now...\n")
        }
        fmt.Printf("addr: %v    val: %v\n", uintptr(p), *(*int)(p))
        p = unsafe.Pointer(uintptr(p) + unsafe.Sizeof(s[0]))
    }
}

https://play.golang.org/p/4vF-7z45PP5

So, what does all this mean for extending a slice? Lets say you reslice a slice s like so:

t = s[a:b]

Then calculating the new slice header for t is trivial, given the header for s:

t.array = unsafe.Pointer(uintptr(s.array) + a * unsafe.Sizeof(s[0]))
t.len = b - a
t.cap = s.cap - a

Notably, this will work for both negative and non-negative values of a and b, assuming the backing array has the capacity.

More importantly, validating that t doesn't extend beyond it's allocated capacity is also trivial, given the above:

if t.len < 0 || t.len > t.cap {
    panic("invalid slice!")
}

Unfortunately, the above assumption only holds if a and b are non-negative. There is no way to check if a re-slice has extended beyond the allocation of its backing array if negative slice indices are allowed, given the type definition of the slice header above. Because of this, negative indices are unsafe under the current slice implementation and not allowed.

That being said, it would be pretty simple to also track the capacity available in front of the pointer by adding another int field to the slice header, and then you could very easily check to ensure the slice is within its allocation for negative indices, but as of now the language authors haven't deemed it necessary.