Finishing up #1564 (add As a.k.a liskov)

[kailuowang]

This is an effort to finish up #1564
complete the missing test with 2 new helper methods for Function1

Closes #1564

[codecov-io]

Codecov Report

Merging #1728 into master will increase coverage by 0.08%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1728      +/-   ##
==========================================
+ Coverage    93.9%   93.99%   +0.08%     
==========================================
  Files         248      249       +1     
  Lines        4101     4129      +28     
  Branches      156      159       +3     
==========================================
+ Hits         3851     3881      +30     
+ Misses        250      248       -2

Impacted Files	Coverage Δ
core/src/main/scala/cats/evidence/As.scala	100% <100%> (ø)
...ain/scala/cats/laws/discipline/CategoryTests.scala	100% <0%> (+16.66%)	⬆️
laws/src/main/scala/cats/laws/CategoryLaws.scala	100% <0%> (+33.33%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3944108...48f539f. Read the comment docs.

[johnynek]

looks great!

Thanks a ton @stew and @kailuowang (and prior scalaz authors).

[sir-wabbit]

Can Leibniz and Liskov type aliases be removed? I am not seeing the rationale behind having extra symbolic type aliases. They could be used for bounded versions of As and Is in the future.

[johnynek]

Can you describe what you mean in more detail? Bounded how?

…

On Wed, Jun 14, 2017 at 20:46 Alexander Konovalov ***@***.***> wrote: Can Leibniz and Liskov type aliases be removed? I am not seeing the rationale behind having extra symbolic type aliases. They could be used for bounded versions of As and Is in the future. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1728 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJdvbbV2bixq9hS8Pfx7EFNU2T3fOUks5sENNBgaJpZM4N3m_1> .

[sir-wabbit]

Similar to https://github.com/alexknvl/leibniz/blob/master/src/main/scala/leibniz/Leibniz.scala
As it currently is, Is[A, B] can not be used to substitute into bounded type constructors such as F[A >: L <: H], even if you know that both A >: L <: H and B >: L <: H.

[johnynek]

I'm confused why you want such a thing rather than just several As instances. Won't As[L, A], Is[A, B] and As[B, H] be the same as your Leibniz?

…

On Wed, Jun 14, 2017 at 20:49 Alexander Konovalov ***@***.***> wrote: Similar to https://github.com/alexknvl/leibniz/blob/master/src/main/scala/leibniz/Leibniz.scala As it is Is[A, B] can not be used to substitute into bounded type constructors such as F[A >: L <: H] even if you know that both A >: L <: H and B >: L <: H. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1728 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJdt62vYmoiovBBL9OU9b69taySYpnks5sENQVgaJpZM4N3m_1> .

[sir-wabbit]

No. You can't get L <: A knowing only L <~< A, at least not with the available functionality of As (there are some tricks that you can do involving existential types, but it won't help with F[A >: L <: H]). The compiler won't let you write F[A] for F[X >: L <: H] because it has to know that such type constructor makes sense. You can't even asInstanceOf it since F[A] (or F[B]) will be a semantic error.

[sir-wabbit]

Having A === B and knowing A >: L <: H and B >: L <: H is enough to justifiably coerce F[A] to F[B] using asInstanceOf. But unless you have a bounded version of Is, you can't do it without asInstanceOf.

[sir-wabbit]

Similarly, having just As[A, H] and a: A is not enough to be able to call def foo[X <: H](x: X): Option[X] as foo[A](a) : Option[A], you need something along the lines of As1.