I'm actually OK with the more concise and obscure notation, but I think we need to note carefully where writability readability trades off against readability, so we can tilt the language toward readability.
On Jan 8, 2019, at 4:07 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > While the aim is perhaps noble, make the code more explicit, your proposal > have the same kind of issues we had before 8 when the compiler was asking to > declare the captured local variables final. > - your proposal transform the problem from "why does it compile ?" to "why it > don't compile ?". Yes, that is almost the definition of a "readability feature": It may be harder to write, but is easier to understand once written. > - if there is no declaration of 's', the error will be reported on 's' at the > last line and most of the users will not know what to do. A straw man, easily fixed by an error message that points at the missed binding and says "did you mean…". > - the IDEs may help, but you should be able to write a basic Java program > without an IDE (in jshell by example) and IDEs may declare 's' at the wrong > place (the wrong scope) anyway. > - Groovy, Kotlin have already this kind of feature and the branding "hey look > the compiler is smart" seems enough. Yep; people are already learning to read such twisty code, so that decreases the need for readability on this feature. > - i'm not even sure it makes the code more readable, at lot of users will not > understand the code because it's like you can use 's' in the then branch ( > 's' is declared above after all ). There's nothing new here: The 's' won't be usable on the then-branch for the usual rules that pertain to definite assignment. I'm assuming that Java students learn early that you can't use a variable that hasn't been assigned yet. — John
