fix: remove redundant map access

[dtam-cybozu]

Remove a redundant check for whether an element is present in a map. Since we return the zero value of a time.Time anyway, it's simpler to use the single return value version to access the map.

Checklist

• I have read the contributing guidelines and signed the CLA.
• I have referenced an issue containing the design document if my change introduces a new feature.
• I have read the security policy.
• I confirm that this pull request does not address a security vulnerability.
  If this pull request addresses a security vulnerability,
  I confirm that I got approval (please contact security@ory.sh) from the maintainers to push the changes.
• I have added tests that prove my fix is effective or that my feature works.
• I have added the necessary documentation within the code base (if appropriate).

I have not added any documentation or tests for this since it is such a small fix.

[aeneasr]

I believe that this will panic if the key does not exist

[dtam-cybozu]

I believe that this will panic if the key does not exist

I don't think this is right. See https://go.dev/ref/spec#Index_expressions

For a of map type M:

• x's type must be assignable to the key type of M
• if the map contains an entry with key x, a[x] is the map element with key x and the type of a[x] is the element type of M
• if the map is nil or does not contain such an entry, a[x] is the zero value for the element type of M

Here is a Go Playground example https://go.dev/play/p/udUlbIUWIfq

[james-d-elliott]

Yeah this will not panic and will return exactly the same output. I would imagine there is a test in this scenario or one could be easily added to prove unchanged function.

[dtam-cybozu]

BTW @aeneasr if the session itself is nil then a call to GetExpiresAt will panic but this is a separate discussion.

Anyway, I've added a test to show this does not panic.

[aeneasr]

Thank you for the follow up - I think I was confused because it would panic if we had a pointer and would try to access it. Since we don't have either, this is fine! :)