I like the high rated answer about what C# does. But on this topic, D had an unreachable code warning until somewhat recently… and it drove me absolutely nuts and I lobbied (successfully) to have it removed. Why? Because it didn’t work with static if things.
Consider the following: bool doit = typeof(T) is int; if(doit) {} else {}
Inside a template function, if you passed an int as T, the constant folder would try to be clever and say this is equivalent to if(true) and thus call the whole else block unreachable. But if you call the same function with a string… now vice versa.
Of course, a better solution would probably be to make the constant folder + unreachable code warning smart enough to recognize these template parameters might vary. The implementation of this was elusive (at least when I looked at it a year ago) however: the template engine runs first, replacing those placeholder T’s with the given type, then it is passed into the rest of the compiler as that function, which doesn’t realize other branches were possible anymore. This could be (and probably should be fixed)… but it’d take an unknown amount of time and the pain was immediate.
(It is just a warning, and you could ignore warnings, right? But the default flags that ship treat warnings as errors, so even ignoring the warning, especially with me as a library developer, since I don’t control the user’s flags, was easier said than done.)
… yes, this is specific to how D’s templates and unreachable code warning was implemented, so somewhat unique, but there is a general concern that I think is applicable to other languages too: what if the compiler is wrong? Feels pretty bad when you know you’re right but the compiler just won’t let you proceed anyway.
Rather, why do our environments even allow us to represent unreachable code or impossible functions? Even stuck with textbased representations, we can still not allow e.g. the Go programmer to type a a := outside of a func def, because it’s an illegal operation. Only allow valid symbols to even be entered!
With a lisp where the reader gives us an ast tree, we could even stat with buttons. A blank page must start with your first parenthesis pair, then you can put text inside it. That can only be an existing func (e.g. a variable declaration) but not a non-existent name…) These could all be buttons, selectable with the number pad (or a click) from all options (with typing text only used for naming new variables, functions or filling strings.) You can have hotkeys taking you out of the existing paren group/moving levels.
With Go, a blank page would let you import, declare variables or define funcs (namely main). You choose the option by clicking the availabe buttons or typing a number. Inside the func, it lets you declare vars, more funcs etc. You can use a hotkey to exit the func or or or…
I’m currently working on an MVP for RS5S (Scheme) and Go.
Personally, I use partially complete code when prototyping. I’ll have unused variables and functions. An if statement may never reach else.
This is an incredibly common workflow for web development.
The last time I tried to learn Go, it fought my normal workflow constantly. I gave up trying to learn it.
I can immediately see the obvious reply that I’m doing programming wrong. Maybe I am from a certain perspective and this post is not for people like me.
You just write them as comments, since they’re marking future intent, ideas etc. just in a precise programming language instead of English. In Go, you then simply uncomment them when you’ll use them.
In my thing, unused variables are fine (unless it’s go.) Indeed, you have to define something to then use it elsewhere! But the commenting workflow is still core, although instead of uncommenting them, you’d retype with the safety rails to avoid errors (since you can type a comment as a literal.)
Once upon a time, I toyed with a similar interface here: https://sat-front.netlify.app. In this experiment, you fill out a CLI-like input. The tool parses what you type and only allows the “submit” button to be enabled if you’ve entered a valid command. The tool also shows you what the next word you type is allowed to be and provides buttons to make entering those words more convenient. (I don’t think any of the commands actually do anything, but it’s been a while)
Expanding this to work as a code editor for a proper language would be incredible! I’d love to see what you build once it gets to a sharable state.
I like the high rated answer about what C# does. But on this topic, D had an unreachable code warning until somewhat recently… and it drove me absolutely nuts and I lobbied (successfully) to have it removed. Why? Because it didn’t work with static if things.
Consider the following: bool doit = typeof(T) is int; if(doit) {} else {}
Inside a template function, if you passed an int as T, the constant folder would try to be clever and say this is equivalent to
if(true)and thus call the whole else block unreachable. But if you call the same function with a string… now vice versa.Of course, a better solution would probably be to make the constant folder + unreachable code warning smart enough to recognize these template parameters might vary. The implementation of this was elusive (at least when I looked at it a year ago) however: the template engine runs first, replacing those placeholder T’s with the given type, then it is passed into the rest of the compiler as that function, which doesn’t realize other branches were possible anymore. This could be (and probably should be fixed)… but it’d take an unknown amount of time and the pain was immediate.
(It is just a warning, and you could ignore warnings, right? But the default flags that ship treat warnings as errors, so even ignoring the warning, especially with me as a library developer, since I don’t control the user’s flags, was easier said than done.)
… yes, this is specific to how D’s templates and unreachable code warning was implemented, so somewhat unique, but there is a general concern that I think is applicable to other languages too: what if the compiler is wrong? Feels pretty bad when you know you’re right but the compiler just won’t let you proceed anyway.
Rather, why do our environments even allow us to represent unreachable code or impossible functions? Even stuck with textbased representations, we can still not allow e.g. the Go programmer to type a
a :=outside of a func def, because it’s an illegal operation. Only allow valid symbols to even be entered!With a lisp where the reader gives us an ast tree, we could even stat with buttons. A blank page must start with your first parenthesis pair, then you can put text inside it. That can only be an existing func (e.g. a variable declaration) but not a non-existent name…) These could all be buttons, selectable with the number pad (or a click) from all options (with typing text only used for naming new variables, functions or filling strings.) You can have hotkeys taking you out of the existing paren group/moving levels.
With Go, a blank page would let you import, declare variables or define funcs (namely main). You choose the option by clicking the availabe buttons or typing a number. Inside the func, it lets you declare vars, more funcs etc. You can use a hotkey to exit the func or or or…
I’m currently working on an MVP for RS5S (Scheme) and Go.
Personally, I use partially complete code when prototyping. I’ll have unused variables and functions. An if statement may never reach else.
This is an incredibly common workflow for web development.
The last time I tried to learn Go, it fought my normal workflow constantly. I gave up trying to learn it.
I can immediately see the obvious reply that I’m doing programming wrong. Maybe I am from a certain perspective and this post is not for people like me.
You just write them as comments, since they’re marking future intent, ideas etc. just in a precise programming language instead of English. In Go, you then simply uncomment them when you’ll use them.
In my thing, unused variables are fine (unless it’s go.) Indeed, you have to define something to then use it elsewhere! But the commenting workflow is still core, although instead of uncommenting them, you’d retype with the safety rails to avoid errors (since you can type a comment as a literal.)
It certainly makes sense to make incorrect things impossible to express by construction. But unreachable code is not incorrect; it’s only redundant.
Once upon a time, I toyed with a similar interface here: https://sat-front.netlify.app. In this experiment, you fill out a CLI-like input. The tool parses what you type and only allows the “submit” button to be enabled if you’ve entered a valid command. The tool also shows you what the next word you type is allowed to be and provides buttons to make entering those words more convenient. (I don’t think any of the commands actually do anything, but it’s been a while)
Expanding this to work as a code editor for a proper language would be incredible! I’d love to see what you build once it gets to a sharable state.