One small concern with the dereferencing logic

[porky11]

I really like the dereferencing logic. It's good for refactors.

For example in C, when you have a reference x and supply it to a function, you would do f(x).
But if you have a struct reference s and want to supply the field x by reference you have to explicitly deref and take the field (normally both at once using the arrow operator) and then take the reference of it like f(&s->x)

In Penne it would like this (if there were structs already):

f(&x);
f(&s.x);

Some other example:

fn test(some_value: i32)
{
    // dozens of uses of some_value like this:
    f(some_value)
}

Now I realize my function has to take the value by reference for some reason:

fn test(some_value: &i32)
{
    // dozens of uses of some_value like this:
    f(some_value)
}

Still works the same way.

Now my concern: The refactored function will implicitly dereference some_value dozens of times. This might cause an unnecessary overhead.

Will the compiler be able to optimize that away?
Or will you need to do it explicitly by defining a function like this:

fn test(some_value: &i32)
{
    var some_value = some_value; // implicitly deref here for performance reasons
    // dozens of uses of some_value like this:
    f(some_value)
}

[SLiV9]

Good question! I think if we ignore multithreading for a moment (which I haven't even begun thinking about), it should be totally valid for the compiler to detect multiple dereferences in a row and optimize them out. In fact I could imagine LLVM already doing that, but I wouldn't be suprised if LLVM is conservative precisely because of multithreading.

I haven't done any performance testing but this is definitely a good test case.