It's not possible to make a view of a non thread local variable declared as var. So the following code doesn't compile:
{.experimental: "views".}
var someArray = [0]
proc main() =
let viewOfArray: openArray[int] = someArray
main()
/usercode/in.nim(6, 37) Error: cannot borrow from someArray, it is not a path expression; see https://nim-lang.github.io/Nim/manual_experimental.html#view-types-algorithm-path-expressions for details
But there's a workaround:
{.experimental: "views".}
var someArray = [0]
proc takeOpenArray(arr: openArray[int]) =
let viewOfView: openArray[int] = arr
proc main() =
takeOpenArray someArray
main()
1. Why is this not allowed? The manual doesn't explain it. (also the link in the error message both doesn't work and why it doesn't work is described in a different section)
The anchor is now #view-types-path-expressions, I suppose the error message wasn't up-to-date.
2. Is my workaround just an oversight? And if yes how will it be prevented, will the creation of the view with the call already be an error?
From the spec this seems to be deliberate:
Let source be one of:
- A formal parameter of p. Note that this does not cover parameters of inner procs.
- The result symbol of p.
- A local var or let or const of p. Note that this does not cover locals of inner procs.
- A thread-local var or let.
- A global let or const.
- A constant array/seq/object/tuple constructor.
Your second example fullfills the 1st case, so it's allowed. Note that if you try to return an openArray from the parameter, you'll see the same error as the first example. Also the view spec only applies to local variables containing the view, not parameters (openArray[T] parameter type would be rather useless if it has the restrictions of local variables applied to it IMO).
This is just my speculation and for a detailed answer you gotta wait for @Araq himself.
View types are part of the memory safe Nim subset and so we have to protect ourselves against mutations of global variables performed by other threads. Your workaround is a nice way to show this protection is not nearly good enough. :-)
Not sure how to solve it. Maybe view types should be restricted to func.
Also notice that view types are still so broken that we didn't announce them for 1.4. :-)