Ark doesn't like it when you use the indexing operator on call expressions

[felixangell]

func foo() -> ^u8 { ... }
...
foo()[0]; // error!

[kiljacken]

In the future, could you include the error log?

On Wed, Mar 2, 2016, 03:43 Felix Angell [email protected] wrote:

func foo() -> ^u8 { ... }
...
foo()[0]; // error!

—
Reply to this email directly or view it on GitHub
#719.

[felixangell]

Oop, sorry. This was just a quick issue at 5am before I went to sleep 😉

[kiljacken]

Happens due to most of our access-expressions only working on other access expressions. The fix will be to not force this in the constructor, I think, and then just leave the work to the type checker.

[kiljacken]

A bit more cursory coding shows me the underlying issue. We currently only allow struct access/array indexing on access expressions. This is due to mutability only being handled for access expressions, and we wouldn't want people to write to a immutable array/struct.

So if we want to fix this we need to move mutability completely into the type system, which is a fair bit of work.

[MovingtoMars]

Eh, I don't think we need to go that far. The result of a call expression should always be mutable. It only becomes immutable when we bind it to an immutable variable. t := do();

[kiljacken]

The main concern is the case where you return an array. We have no other way to specify that the backing array is immutable, and we need a way to express this. Take this example:

// immutable
data := []int{0, 1, 2, 3, 4};

func ohBoy() -> []int {
    return data;
}

func main() -> int {
    mut array := ohBoy(); // and now we can theoretically modify data, even though it is immutable
    array[2] = 42; // no errors here (well, probably from llvm, but not from us)
}