2 ms·

The Rust example provided isn't showing what the author seems to claim it's showing, which is interesting. You see, that function named iter() isn't some trait

The Rust example provided isn't showing what the author seems to claim it's showing, which is interesting. You see, that function named iter() isn't some trait feature, it's just a convention. So this is a coincidence, of exactly the sort which could arise regardless of a feature like traits. Option::iter() is a function defined on the Option type, and [T]::iter() is a function defined on slice types [T]. The Vec is getting coerced into a slice to call that iter() function in the case where there's a Vec here. These functions do similar things because of the convention, but they could in principle have completely unrelated behaviour -- it's just a convention -- and this would still compile. For example suppose we instead change allow_list to my custom Doodad type. Doodad can cheerfully provide a method named iter() which gives you a Debretts (Debrett's publishes a notable guide to British Peerages) and my Debretts type has a method count() which tells you how many counts and countesses there are currently for some reason (zero, England doesn't use this title). That compiles just fine, not because "Ad-hoc polymorphism erodes type safety" but because we just wrote iter().count() and we get whatever that does, if we wanted to say "I assert iter gives me an Iterator over items of type ClientIdentifier", we can say that, but we did not.

karmakaze 3y ago
I was expecting/hoping to learn something new, and instead only came to this same realization. The most I could say is that interfaces/etc can sometimes give a false sense of (type) safety. On finding the cause of such a fault, I don't shake my fist at interfaces, I say "Doh! I should know better." > Some responders seemed surprised by this idea, and I thought this was common knowledge but could not find any blog posts about it either. I figured maybe it was worth writing out, and some people agreed, so here we are: The idea is both surprising and common knowledge. Surprising to think that it's a special kind of type weakness, rather than a common one where actual cases are not surprising at all. Nice writing, more substantial content would be great! If we take away all the big words, use Java instead of Haskell/Rust and start with the example that breaks, it would be a much shorter post that no one would care to read. I don't know that the great writing and build-up is worthwhile, other than a pleasant if somewhat disappointing read.

karmakaze 3y ago

I was expecting/hoping to learn something new, and instead only came to this same realization. The most I could say is that interfaces/etc can sometimes give a false sense of (type) safety. On finding the cause of such a fault, I don't shake my fist at interfaces, I say "Doh! I should know better." > Some responders seemed surprised by this idea, and I thought this was common knowledge but could not find any blog posts about it either. I figured maybe it was worth writing out, and some people agreed, so here we are: The idea is both surprising and common knowledge. Surprising to think that it's a special kind of type weakness, rather than a common one where actual cases are not surprising at all. Nice writing, more substantial content would be great! If we take away all the big words, use Java instead of Haskell/Rust and start with the example that breaks, it would be a much shorter post that no one would care to read. I don't know that the great writing and build-up is worthwhile, other than a pleasant if somewhat disappointing read.