Jason, thank you for that link! After reading much of the prior discussions on the matter, it's clear Oliver Woodford and I share a similar viewpoint, and this has already been discussed heavily.
I would still vote for covariance over invariance in this case, since arguments to functions map fine to his "correct for read" analogy. But since this topic has already been so heavily discussed, I'll leave it alone and just be ok with the fact that my code is just a little bit uglier than it needs to be, but works fine. On Sunday, May 25, 2014 8:13:32 PM UTC-4, Jason Merrill wrote: > > See also > https://groups.google.com/forum/#!searchin/julia-users/invariance$20covariance$20contravariancefor > discussions of different possibilities for handling inheritance with > typed parameters. I was convinced by Stefan's arguments there that Julia's > invariance is the least bad strategy. > > On Sunday, May 25, 2014 4:32:42 PM UTC-7, Adam Smith wrote: >> >> I agree to be as generic as possible. I should have used this second >> example instead, a quite common scenario where being generic doesn't make >> as much sense: >> >> function output(context::Context, strings::Vector{String}) >> context.something() >> # Call the single-string version of the function on each item >> for string in strings output(string) end >> end >> >> output(context, ["Hi there"]) >> >> I have already encountered this pattern a number of times in just my few >> weeks with Julia; wrapping a function with a version that takes a single >> item with one that takes a collection of them. >> > > At the risk of being annoying by criticizing a purposely simplified > example, I think you should be careful about over-applying this pattern. As > you point out, using the same method for containers and values gets you > into sticky type territory, and Julia already provides lots of convenient > ways for users to apply a method over a collection. > > The convenience you're trying to provide might not always outweigh the > tradeoffs. >
