[
https://issues.apache.org/jira/browse/GROOVY-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478097#comment-16478097
]
mgroovy commented on GROOVY-8570:
---------------------------------
@[~paulk]: But how is someone to tell that "var" is bad style, and "def" is not
? How are you going to reach all those people that downloaded Groovy in the 1st
quarter of 2018 ? I still don't get what you dislike about warnings so much...
Anyway, I don't think I can convince you, so would you support (on the mailing
list) me creating a IntelliJ ticket, to add a "var is not idiomatic Groovy use
def instead" warning (and one for the curly braces array literal, if that will
happen) to IntelliJ ? It is much harder to "totally ignore" these warnings,
there are already tons of Groovy Intellisense warnings that are enabled by
default in IntelliJ, and we would at least reach the IntelliJ users.
> Support Warnings in Groovy Compiler
> -----------------------------------
>
> Key: GROOVY-8570
> URL: https://issues.apache.org/jira/browse/GROOVY-8570
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
> Affects Versions: 3.0.0-alpha-3
> Reporter: mgroovy
> Priority: Major
>
> * To warn Java developers using e.g. non-idiomatic Groovy constructs which
> only exist to support copy-and-paste Java-to-Groovy code compatibility, The
> Groovy compiler should support compiler warnings in addition to compiler
> errors.
> * Warnings should by default only be emitted in special circumstances such
> as the one described above, and not spam developers with an endless stream
> of, often subjectve, messages on "how to use Groovy correctly".
> * Sample warnings:
> # WARNING: Using curly braces Java style array literals (\{...}) is not
> idiomatic Groovy. To avoid confusion with Groovy closures, it is recommended
> to use the performance-identical Groovy square bracket list literal syntax
> ([...]) instead.
> # WARNING: The 'var' keyword is currently only an alias to 'def' (i.e.
> Object) in Groovy. To get reassignment type safety use an explicit type
> instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
