R.__ missing

[Willmo36]

Hey,

The definition for R.__ (http://ramdajs.com/docs/#__) is missing, is this intentional?

I've tried merging the Static interface with a local definition but it doesn't want to play nice :(

declare namespace R {
    interface Static {
        __(): any;
    }
}

Update 1

After some more adventures I'm not sure what the type should be either. I modified the index.d.ts in my node_modules/@types/ramda to include __ like the following:

interface Static {
        __(): any;
        ...

But I then couldn't do R.gt(R.__, 0) as R.gt is (a: number, b:number) => boolean.

This lead to me just defining R.__ as just any (not a function at all) in the interface.

Update 2

const R__ = (R as any).__ works.

[KiaraGrouwstra]

I can take a PR for that. We hadn't managed to get it to play nice for type inference either though. For arity-2 functions, hopefully R.flip would work better...

[KiaraGrouwstra]

Sorry, checked into this again but I realize why donnut had taken this out. Even if you put in any, it'll screw up the rest of the typings as it won't understand what happened. With that, the placeholder is essentially pretty harmful to use with typescript-ramda, hence the README note recommending R.flip instead when possible (binary functions).

I can foresee a 'proper' solution -- handling every possible combination on the level of the CurriedFunction interfaces, which would prevent having to do this for every single function (as if just the currying wasn't bad enough).
However, that kind of requires being able to have all functions go through that interface in the first place, which is something I tried to do (added commented versions) but hadn't quite managed to make work yet, see #122. So I fear at the moment I'm not able to fix this yet.

As a temporary fix, I'm hesitating a bit about reverting donnut's removal considering how bad of an idea this might end up as. That said, having compilation errors show up due to inclusion of these typings would kind of suck, especially considering e.g. Ionic will just cancel your build (previously angular-cli did too).

With that in mind, I'd like to relieve your pain here. It'll still be broken, though I suppose technically it might be considered slightly less broken than erroring as soon as you even invoke R.__. With that in mind, I'm inclined to reluctantly merge in your any suggestion as a temporary hacky workaround.