-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make openArray first-class #88
Comments
I don't see how this can be supported in a memory-safe way. Well ok, I do know how to do that (borrow checking), but I don't think it's worth the costs. |
hence the |
If he knows what he is doing he is free to use |
Duplicate of closed nim-lang/Nim#5437 Discussions with several proposals to read: https://github.com/nim-lang/Nim/issues/7337#issuecomment-373444925. (in the context of I feel like we are closing Openarrays/Views/Slices/Ranges/Spans feature requests very early. |
|
Well but you want to slice into the data so you want control over the length too. |
yes, but as in all (or most?) proposals that I've seen, the length should be part of the object returned by toOpenArray / toSpan / etc: let (pr, n) : (ptr int, int) = get_pointer_length(...) # eg, from C proc, etc
# with 1st class openArray:
let a=toOpenArray(pr, 0, n-1) # a is openArray[int]
doAssert a.len == n
# alternatively, if openArray can't be made 1st class for some reason: with Span:
let a=toSpan(pr, 0, n-1) # a is Span[int]
doAssert a.len == n
|
* Add `toOpenArray[T](ptr UncheckedArray[T])` for clarity. `ptr array[0,T]` for some unchecked type already works but A) `UncheckedArray` seems to be the intended future way for this kind of access, and B) essentially all use cases will have a `ptr` for that kind of array source and this call signature lets callers drop the trailing `[]` corresponding to that `ptr` deref. This PR relates to issue https://github.com/nim-lang/Nim/issues/9001 . * Add a test for toOpenArray() for UncheckedArray[T]s.
/cc @Araq /cc @mratsim also for your comment |
* Add `toOpenArray[T](ptr UncheckedArray[T])` for clarity. `ptr array[0,T]` for some unchecked type already works but A) `UncheckedArray` seems to be the intended future way for this kind of access, and B) essentially all use cases will have a `ptr` for that kind of array source and this call signature lets callers drop the trailing `[]` corresponding to that `ptr` deref. This PR relates to issue https://github.com/nim-lang/Nim/issues/9001 . * Add a test for toOpenArray() for UncheckedArray[T]s.
* Add `toOpenArray[T](ptr UncheckedArray[T])` for clarity. `ptr array[0,T]` for some unchecked type already works but A) `UncheckedArray` seems to be the intended future way for this kind of access, and B) essentially all use cases will have a `ptr` for that kind of array source and this call signature lets callers drop the trailing `[]` corresponding to that `ptr` deref. This PR relates to issue https://github.com/nim-lang/Nim/issues/9001 . * Add a test for toOpenArray() for UncheckedArray[T]s.
--experimental:views should be enough to close this? Given #12 was closed |
It's far from a working design, and prevents many use cases, I don't think we should close this. |
We need a follow-up RFC. |
It works reasonably well and things are improving incrementally. |
I didn't find an issue to track this, it's only mentioned in comments in random places, eg [1][2].
proposal
allow:
openArray
can be implemented as something similar to:It could be enabled via a
-d:unsafe_openArray_firstclass
(and assert at runtime with this flag is not passed)links
[1] nim-lang/Nim#5957 (comment)
[2] nitely/nim-graphemes#4
EDIT
The text was updated successfully, but these errors were encountered: