[TODO] fix issue #8303 map overly restrictive

[timotheecour]

/cc @dom96 @Araq this workaround for #8303 doesn't work yet: I just hit the limitation of #7435 (type inference with lambdas doesn't work) again. Help would be appreciated:

in #8272 adding this innocent looking code:

proc quoteShellCommand*(args: openArray[string]): string = args.map(quoteShell).join(" ")

results in travis/appveyor failure (see bug) because sequtils.map cannot handle cdecl procs andquoteShell becomes a cdecl in the --define:createNimRtl test of travis/appveyor:

proc map*[T, S](s: openArray[T], op: proc (x: T): S {.closure.}): seq[S]{.inline.}

but trying to make map less restrictive as in this PR results in exactly the type inference bug I had mentioned here (#7435), see where below in [1]

How do I solve this (without the workaround of using an explicit for-loop in quoteShellCommand or similar, which is just hiding the problem under a rug, waiting to re-occur?

is there at least a way to be generic on the pragma type, to allow both decl and cdecl?

proc map*[T, S, Pragma](s: seq[T], op: proc (x: T): S {. Pragma .} ): seq[S]= # this unfortunately doesn't work:

The following DOES work but is really ugly, it's not DRY:

proc map*[T, S](s: seq[T], op: proc (x: T): S ): seq[S]= ... <function body>
proc map*[T, S](s: openArray[T], op: proc (x: T): S {.cdecl.}): seq[S]{.inline.} = ... <function body>

I also tried:

template map*[T](s: openArray[T], op: untyped): auto =
  var res = newSeq[type(op(s[0]))](s.len)
  for i in 0 ..< s.len:
    res[i] = op(s[i])
  res

but gives: Error: A nested proc can have generic parameters only when it is used as an operand to another routine and the types of the generic paramers can be inferred from the expected signature.
(x) => x.changeFileExt("").toLowerAscii()

[1] with this PR, travis/appveyor (or running ./koch nimble locally) complains about this:
at dist/nimble/src/nimblepkg/packageparser.nim(103):

normalizedBinNames = pkgInfo.bin.map(
      (x) => x.changeFileExt("").toLowerAscii()
    )

[GULPF]

I think map could support {.cdecl.} by changing the signature to this:

proc map*[T, S](s: openArray[T], op: proc (x: T): S {.closure.} | proc (x: T): S {.cdecl.}): seq[S]{.inline.}

I don't really understand why the calling convention is part of the type in Nim though. Shouldn't higher order procedures like map be able to accept parameters with any calling convention?

[Araq]

andquoteShell becomes a cdecl in the --define:createNimRtl test of travis/appveyor

Probably it shouldn't then? This needs to be solved differently, we need to map nimcall to cdecl for DLL building, and maybe in general.

[Araq]

This needs to be fixed differently. Closing.

[timotheecour]

andquoteShell becomes a cdecl in the --define:createNimRtl test of travis/appveyor

Probably it shouldn't then? This needs to be solved differently, we need to map nimcall to cdecl for DLL building, and maybe in general.

maybe I'm not understanding what you're suggesting here, but whatever we do I think we should allow map to work with a proc whether it's cdecl or not.
So far @GULPF 's suggestion in #8325 (comment) is the least worst, and simplest until a better fix is found (either genericity on pragma or fixing #7435)