People want to write methods, but forget the =. In the worst case, the result is silently swallowed and the bug manifests itself only later at the use-site, not at the point of declaration.
The exact same complaint could be registered about any function that doesn't have an explicit return type, yet there is no move to make that mandatory.
No. If the method has no explicit return type, it is inferred. It's really reducing the usefulness of type inference if a trivial error can flip the switch from "the return type is computed from the last expression of the method body" to "the method body is ignored completely, and () is returned instead".
Apart from that, there is a move to make explicit return types mandatory in some places; for instance when defining implicit conversions or when declaring abstract methods in traits.
And yet, if there is an idiomatic Scala (and the lack of one is a huge problem with the ecosystem) it's that nobody uses function syntax for Unit return types. So in order to get rid of a class of bug that is minuscule compared to others you are going to require hundreds of thousands (millions?) of lines of code to be changed. It's that kind of lack of real world perspective that causes the Scala community to be derided.
The most recent version of the Xlint/future features are useless because of this blind spot making so much noise in the output.
> And yet, if there is an idiomatic Scala (and the lack of one is a huge problem with the ecosystem) it's that nobody uses function syntax for Unit return types. So in order to get rid of a class of bug that is minuscule compared to others you are going to require hundreds of thousands (millions?) of lines of code to be changed.
If there's an automated conversion tool, who cares?
No, you'll have to review the patch yourself. We also don't indemnify you when we introduce a regression. We do have support contracts for those who want the fastest turnaround in fixing those...
How many LOC are you responsible for maintaining? Of all the confusing things in Scala the procedure vs method syntax seems like a trivial one, yet in deployed code bases most people use the procedure syntax. It has become a defacto standard. That the language designers got it wrong is bad, but not worse than the fix (or if they are going to "fix" this they should do it more slowly and not screw up Xlint/future).
I agree it's not the most confusing thing about Scala. It just doesn't help. It doesn't confuse me now (I remember programming languages were the distinction between function and procedure is important), but it makes little sense and I'm glad this syntax is removed for future generations of Scala devs.
Scala is a relatively new language that already has made too many concessions to backwards compatibility with Java, resulting in a less elegant language than it could have been. I'd rather they broke compatibility a few more times and got rid of their earlier mistakes.
This is not very important, though. I'd rather they focused on other, more important improvements first.
It's not a minuscle bug. Some older thread where people discussed this showed that it is a huge issue in practice.
The change to method syntax is both binary and source compatible (forward and backward); and as mentioned in the article no one is expected to do it manually.
Additionally, compiler warnings will become configurable, so that developers can choose which warnings add the most benefit to their workflow.
I've written/read/reviewed lots of Scala code and can't remember seeing it be an issue. Certainly not a huge one. I'd like to see a pointer to that thread if you can find it so that I know what to look out for. Maybe include that as justification in the SIP.
If this was such a `huge` issue, I strongly question how code of such importance would be written without a unit test accompanying it that calls the method at least once. If you are going to write code where having unit inferred is going to be a 'huge issue' what the %$&# are you doing not unit testing that method? Is it reasonable to assert we make the unit test harder to write (unit tests are typically procedures) and make this bug even work to catch in the first place?
If this is done with a -Xlanguage flag or made as opt in warning then that sounds very reasonable. It's going to be a lot worse if the first thing a newbie sees when they copy paste a main method in from an old tutorial is 'Error: Procedure syntax is deprecated'. No matter what the parser is going to have to parse the procedure syntax anyhow, in order recognize that form and give a reasonable error message for new users copy pasting in code. So it's not like we all that parsing code disappears.
>Additionally, compiler warnings will become configurable, so that developers can choose which warnings add the most benefit to their workflow.
My understanding was/is that this is going to become a compiler error. If it is going to just be an opt-in -XLint:procedureSyntax thing, then why isn't it being done for 2.11.3 ??? If the plan is just to make an opt-in warning I can rest easy, because I will simply never turn that linter warning on. I would however suggest to consider making it a -Xlanguage so that like postfix ops it can be disabled/enabled where needed.
The warning is already there: -Xfuture -deprecation.
We decided to delay making it a plain deprecation until we have said tool to do help you stay deprecation-warning-free. You are addressing deprecation warnings in a timely fashion, yes? :-)
