-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add toOpenArray[T](ptr UncheckedArray[T])
for clarity.
#9316
Conversation
…,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 .
It's slightly dangerous since you turn something unsafe (a If accepted add a test please. |
There's no question of the safety conversion and the opportunity for a problem if the user passes the wrong len, but note this also already happens with the |
It'll be accepted if you name it |
Ok. If you're sure you want that name. The returned object is actually safer as mentioned in my comment above, but the conversion itself is as unsafe as the arguments. So, that ambiguity of "Unsafe" applying to source or destination is one potential confusion. Plus there's no |
Well now, you got me thinking ... |
I think |
Oops. I meant to say |
Ok. Tests passed as promised, and surprisingly there are still no merge conflicts after the big test file consolidation. :-) Let me know your final naming decision, and I'll rename (if necessary) and push that. Personally,
|
Oh, it's fine this way, somebody will bring up the "generic programming!" argument and the type is unsafe, so its usage doesn't have to be marked as such, consistency with |
Yeah. Cool. This is actually even a |
Might as well add the castOpenArray of ptr + len ;) (until openArray becomes a first class type) https://github.com/nim-lang/Nim/issues/5753 |
Well, just for the record, I'm not against adding a It should perhaps be noted for casual readers of these closed issue threads or would-be documenters that |
* 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.
This pull request would let users replace code like this:
with code like this:
In both cases,
get
is just someproc get*[T](x: openArray[T], i: int): T
,myObs
is some instance ofMyTypes
, andn
is some length computed at run-time. I elided those to more starkly show the difference.I don't know if that improves the ergonomics enough to close https://github.com/nim-lang/Nim/issues/9001, but it is a pretty simple change maybe worth consideration.