Add proc toOpenArray[byte] for strings

[data-man]

No description provided.

[ghost]

So user should use first argument as an uint instead of int because there's no result type overloading? It seems like not the best solution, but idk..

[data-man]

because there's no result type overloading?

Yes.

It seems like not the best solution

Maybe toOpenArrayByte will be better.

[Araq]

Maybe toOpenArrayByte will be better.

Yeah...

[data-man]

Renamed.

[Araq]

Ok, now the question is: Why do we need it?

[data-man]

E.g. for compressions/conversions.

proc compress/convert(bytes: openarray[byte]): seq[byte] =

Maybe can be used in the critbits module.

[mratsim]

For crypto

[data-man]

And would be great if proc toOpenArray*[T](x: T): openarray[byte] {.magic: "Slice".} will be implemented for any T with fixed size.
And proc toOpenArray*[T](x: seq[T]): openarray[T] {.magic: "Slice".}
And proc toOpenArrayByte*[T](x: seq[T]): openarray[byte] {.magic: "Slice".}
And proc toOpenArrayByte*(x: string): openarray[byte] {.magic: "Slice".}
:)

[data-man]

Also many procs from strutils can be adapted for openarray[T].
It will be very useful.
Maybe within a new module, e.g. oautils.

[coffeepots]

This fails for the cpp target for me with --cc:vcc (64 bit):

error C2664: 'void foo_2qb8oX71x3XZ4LiDnKOl6w(NU8 *,NI)': cannot convert argument 1 from 'NIM_CHAR *' to 'NU8 *'

note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

The line that raises the issue:

foo_2qb8oX71x3XZ4LiDnKOl6w(str_PePXyhboa11u24CvmKb3Vg->data+(((NU) 0)), ((str_PePXyhboa11u24CvmKb3Vg ? (str_PePXyhboa11u24CvmKb3Vg->len-1) : -1))-(((NU) 0))+1);

[data-man]

Well, closed.

[ghost]

@data-man why?

[ghost]

Maybe it can be fixed

[data-man]

@Yardanico Because @Araq are against it. :)

[coffeepots]

@data-man we shouldn't be getting gen errors in Nim, so this is a valid bug that has been caught by your PR.

As others mention, it could well be useful for various low level processing.

[zah]

It turned out that we need this in quite a lot of places. @Araq, any chance that we'll reconsider merging it?

[yglukhov]

This doesn't need to rely on magic, openarrays can be constructed from ptr/len and produce good codegen. We might add ptr/len to openarray conversion to stdlib though, as it is not obvious enough.

[Araq]

any chance that we'll reconsider merging it?

Ok.