“Option” is the operative word. A type that does not implement the correct trait cannot be used in a way that requires the trait. If you are writing anything non-trivial that would probably be preferable. It requires nothing, that is the default behavior, so I did not bother to mention it.
The options for the thing being constructed are all separate types from the thing being constructed; the options aren’t a facet of the definition of the type they mutate.
I think the point is that `&TraitFoo` would never be expected - that there was no way to have that be the type of a term in the first place? I don't think that can reasonably be said to be true in the days of impl trait though.
I think that when the OP mentioned optional typing, they were probably thinking of a gradual type system. So there would be a design choice to fall back to an ‘any’ type when a better type cannot be inferred. I would also assume that the OP is also not requesting higher ranked types, which also makes some things easier.
Yea, traits make this much simpler to avoid. The problematic type would not match the trait, likely leading to much simpler communication of the error.
reply