> For any expression NOT involving "return", I can write, for example: > const Z = <expr> > but I cannot if <expr> contains a return embedded somewhere.* Sur

> For any expression NOT involving "return", I can write, for example: > const Z = <expr> > but I cannot if <expr> contains a return embedded somewhere.* Sure, but that's not special about this case at all. I also can't write 'break' or 'continue' when I'm not inside a loop. When declaring a 'const', I am lexically not inside a function body, so I can't use 'return', which makes sense (the compiler will even tell you, "return statement outside of function body"). Particular statements being allowed in some contexts but not in others is entirely normal. > My point is that none of this is necessary at all Maybe it's not necessary, but I like the consistency this provides ("everything has a type"), and I imagine the implementation of the type checker/inferer is more straightforward this way. Sure, you could define the language such that "a 'return' in a position that expects a typed expression will not affect other type that need to match with it" (or something else, in better, formal language). Or you can just define those statements to have the 'never' type, and not worry about it. But ok, let's agree that it's not necessary. Then we're just talking about personal preferences, so there's no right or wrong here, and there's no point in arguing.