=== for enum types and type safety

Support dry-types
1

I have noticed the following:

MyEnum = Types::Strict::Symbol.enum(:a, :b)
MyEnum[:a] === :a
# =>true

Don’t you think that it is breaking the type safety that it should provide? I mean, I think it should guarantee that you are not going to use a wrong MyEnum in any case, but if you can use plain symbols in place you are overpassing it. For example:

def test(x)
  case x
  when MyEnum[:a]
    "a"
  when MyEnum[:b]
    "b"
  else
    "I shoould have raised"
end

test MyEnum[:c]
# => Dry::Types::ConstraintError ...
test :c
# => "I should have raised"
2

I’m afraid I either don’t follow or you simply expect from dry-types what’s not possible. MyEnum[:a] in your example returns :a back, it’s a symbol, not something dry-types-related. After that you call === on that object and, again, it’s Symbol’s behavior, not one from dry-types. And note that semantically-wise === cannot raise an exception in any case. If you want to get a constraint error use MyEnum[x].

3

Oh, sorry!! Apologies… it was Friday evening after a tiring week O_o

It was my first time using dry-types and I made wrong assumptions. I didn’t realize that [] method returned the underlying ruby primitive. Instead, I supposed it was returning an instance representing a dry-type value.

I see that, with current design, all the responsibility of type safety relies on the callee, while the caller can always send everything he wants. This is different than in a static typed language, but surely it is what makes more sense in a dynamic language like ruby. Otherwise dry-types surely would become a too invasive dependency.