Added 'openArray[char]' overloads to 'std/parseutils'

[beef331]

No description provided.

[beef331]

Seems an issue will be converters to string do not fire for openarray[char]. Perhaps for converters string should work with openArray[char]?

[Araq]

Seems an issue will be converters to string do not fire for openarray[char]. Perhaps for converters string should work with openArray[char]?

Nah, it's fine this way IMO. The real issue is here that it's a breaking change which would be easily avoidable by introducing duplication in the form of a new std / parseslices module.

[beef331]

In the case where people want a 'weak distinct' it would give the ability to optimise a copy away as the following. Given openarray[char] cannot be used in a converter one cannot really do this.

type NotString = distinct string
converter toString*(s: NotString): lent string = string(s)

[Araq]

I understand the problem but introducing "converter chaining" at this point would be far too an invasive change. So the next best option is str / parseslices

[Varriount]

This is a kludgy hack. Is there any alternative to creating a copy of an entire module? Why can't the duplicate functions just be added to parseutils?

I understand the problem but introducing "converter chaining" at this point would be far too an invasive change.

Even if it's only for special cases (like openarrays)?

[beef331]

Why can't the duplicate functions just be added to parseutils

I forgot that openarray[char] and string did not cause a mismatch with converters, so I guess it could be added there, make all the base procedures operate on openarray[char] but have the string versions call the openarray variants.

[Araq]

Even if it's only for special cases (like openarrays)?

Especially if it's only for special cases. These come back and bite you. ;-)

[planetis-m]

For custom string types it's nice to have implicit converters to openArray:

{.experimental: "views".}

converter toOpen(x: MyString): openArray[byte] =
  toOpenArray(x.data, 0, x.data.high)

although I don't know if this is the direction we are going, or is it going to cause problems?

[Varriount]

although I don't know if this is the direction we are going, or is it going to cause problems?

The direction I'd like here is to solve this problem in a simple way, that minimizes redundancy. Ideally by just adding overloads and/or type constraints to procedures in parseutils.

[Araq]

Adding overloads that support openArray[char] seems to be the best option for now.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from ea0e45e

Hint: mm: orc; opt: speed; options: -d:release
164024 lines; 8.340s; 613.145MiB peakmem

[ZoomRmc]

Closes #14810