search

nitely / nim-regex

Pure Nim regex engine. Guarantees linear time matching
https://nitely.github.io/nim-regex/
MIT License
228 stars 21 forks source link

regression with latest nim: regex.nim(211, 21) Error: ambiguous call; both unicode.align #30

Closed timotheecour closed 6 years ago

timotheecour commented 6 years ago

/cc @araq https://github.com/nim-lang/Nim/commit/8960efa3407481becf8cdc7151f93a1e789c353a probably caused this; I guess it's ok to overload align+friends (even though this type of breakages can happen) /regex.nim(211, 21) Error: ambiguous call; both unicode.align(s: string, count: Natural, padding: Rune)[declared in ../../../Nim/lib/pure/unicode.nim(1956, 5)] and strutils.align(s: string, count: Natural, padding: char)[declared in ../../../Nim/lib/pure/strutils.nim(1048, 5)] match for: (string, int)

nitely commented 6 years ago

Well, my guess is this will keep occurring unless all strutils are renamed to somethingAscii, or all unicode proc are renamed to somethingUnicode, or unicode implements enough utilities so strutils is no longer needed.

timotheecour commented 6 years ago

unicode implements enough utilities so strutils is no longer needed

i don't think that can happen, my understanding is strutils variants will always be more efficient (and we wanna optimize the common case of ascii)

nitely commented 6 years ago

I didn't mean in general (as in removed from stdlib), but in places where unicode is used for something else and perf does not matter.

2018-10-15 2:25 GMT-03:00, Timothee Cour notifications@github.com:

unicode implements enough utilities so strutils is no longer needed

i don't think that can happen, my understanding is strutils variants will always be more efficient

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/nitely/nim-regex/issues/30#issuecomment-429712664