Not necessarily. T(x) and convert(T, x) could only be interchangeable if T is primitive or if conversion is exactly equivalent to constructing a struct T’s fields from x. For a counterexample, Ref(Ref(1)) versus convert(Ref, Ref(1)).
That is even more horrific to me because that’s not a valid type. I find it pretty important especially to beginners that different things are not written in visually similar but non-interchangeable ways for different contexts. The human brain likes to connect and extrapolate, so either keep things the same or very different.
Even for left hand annotations? That could be helpful, actually. Just throws an error in your face if you didn’t intend for a conversion.
Taking this all together, it could be justifiable that there be a different annotation syntax for additional conversion, could even make it an infix operator to replace convert calls.
Funny you mention that because I’m not a fan of how there’s multiple function syntaxes (named function, named =, nameless function, anonymous ->. It’d be more okay if they had the same features, but parsing difficulties means they actually don’t. If function and end were too long, I’d rather they’d just be shortened. Rust does fn which seems clear enough, but I wouldn’t know what could replace end; my first instinct is a simple spaced period but seems weird. Anyway, if -> syntax is removed, then -> could actually be a drop-in replacement for :: meaning “assert but also convert first”.