`food.Resource` is idiomatic for a type conversion, but perhaps we shouldn't reject alternatives so abruptly, especially when three(!) syntaxes are on the nice list.
`(Resource)food` is C syntax for type casting, there's precedent, we can expect at least some people to understand what's going on. Used consistently, it could make distinguishing between method calls and type conversions clearer to a reader. A counter-argument is that `food.Resource` is already unambiguously a type conversion, due to the convention that only types begin with a capital letter, and another distinguishing convention is superfluous. However, typedescs as parameters exist, and I find it reasonable that a context could exist where the extra cue could be helpful to a reader. Furthermore, I argue that `Resource food` is less clear than `(Resource)food`. if the first is acceptable, surely the second should be considered. Nim has many ways of expressing the same thing, if used consistently within a codebase to concisely communicate to a reader I don't think any valid syntax should be rejected out of hand. Nim house style is for identifiers to be in camelCase, and I react as viscerally when I see snake_case used for stdlib calls as anyone, but their interoperability is built into the language, again, as long as used consistently within a codebase, either convention is valid. As a final example of when I actually would use this unusual syntax: `(foo bar) baz` can be clearer when emulating functional languages.
