Fix #62

[gabbhack]

• Supports more than one pragma parameter (returns tuple)
• Returns nil if there are zero parameters in the pragma (like std)

[zah]

getCustomPragmaFixed was introduced quite some time ago when getCustomPragma from the standard library had a number of issues preventing real-world usage within our libraries. Since then, I've helped the Nim team fix the issues and I don't see any reason for new users to depend on getCustomPragmaFixed. It's kept around only because we haven't invested the time to rework the code that was based on it. What is your use case and why can't you rely on getCustomPragma? To clarify further, instead of changing the API here, we are likely to just drop getCustomPragmaFixed in favor of the standard library.

[arnetheduck]

@zah can we provide a compatibility shim so that anyone depending on the version in stew is redirected to the upstream one instead? we can mark it as deprecated or whatever, but if possible, we shouldn't unnecessary break user code

[gabbhack]

@zah
I am writing another library for deserialization, and I ran into the problems already described in nim-lang/RFCs#176 (where I found this library):

• Fail with generics objects (hasCustomPragma fails on nnkVarTy/nnkBracketExpr nodes nim-lang/Nim#11923)
• Fail with object variants (Custom pragma ignored on field of variant obj if in multiple branches nim-lang/Nim#11415)
• Fail with pragmas on case field (Can't attach a pragma to a cased field. nim-lang/Nim#14511)

[zah]

I'm willing to accept this patch, but it would be a breaking change for a number of our internal packages that already use getCustomPragmaFixed:

https://github.com/search?q=org%3Astatus-im+getCustomPragmaFixed&type=code

Would you agree to take a look at the usages and submit suitable PRs for all projects?

[zah]

Actually, I think I misunderstood the description and this is not really a breaking change. Apologies.