On Mon, 10 Jan 2022 at 23:04, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Most of the effort of learning to read type expressions, in any language, is learning their semantics, which is very different from value expressions. Whether they happen to superficially resemble other parts of the language is pretty much irrelevant to me.
While this is true, what *is* a problem with having a different language, is that you have two very similar syntactic constructs ("expression" and "type expression") and you have to learn which can be used where. And that's actually not as trivial as you'd think at first. The typing.cast function takes a type expression as its first parameter. If type expressions are not expressions, syntactically, then that means that typing.cast(MyType, obj) is *not* syntactically a function call. So what is it? Say it's a new syntactic element, a "cast expression". Then the syntax for an expression must be extended to include cast expressions. And what *is* the syntax of a cast expression? "cast_literal(type_expr, expr)"? Then what's "cast_literal"? The value "typing.cast"? What about "from typing import cast", or "import typing as t" with "t.cast", or "from typing import cast as typecast", or even "my_cast = getattr(typing, "cast")? Suddenly there are a huge number of unanswered questions to be considered, and the answers to those questions need to be learned by people. Paul. PS Having said that, existing type checkers may or may not recognise all of the possible ways to call the cast function that I described. Do we want to mandate what type checkers do as part of the language definition? Do we want to restrict the language definition based on what 3rd party type checkers can achieve?