From 66469e04fe35e5ceb3723cb563379a03e4883101 Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Tue, 6 Feb 2018 22:12:42 +0100 Subject: [var] various upgrades to var: * var is promoted to the main package. * It is no longer an opt-in thing. * bug: var (unlike val) is allowed in old-style for loops, but if you multi-init: for (var i = 0, j="Foo";;), you now get an error that you can't do that. * tests both for the multi-for situation and the new main package variant. --- website/templates/features/experimental/var.html | 37 ------------------------ website/templates/features/index.html | 4 +++ website/templates/features/var.html | 27 +++++++++++++++++ 3 files changed, 31 insertions(+), 37 deletions(-) delete mode 100644 website/templates/features/experimental/var.html create mode 100644 website/templates/features/var.html (limited to 'website') diff --git a/website/templates/features/experimental/var.html b/website/templates/features/experimental/var.html deleted file mode 100644 index fa35ac5e..00000000 --- a/website/templates/features/experimental/var.html +++ /dev/null @@ -1,37 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="var" logline="Modifiable local variables with a type inferred by assigning value."> - <@f.history> -

- var was introduced in lombok 1.16.12 as experimental feature. -

- - - <@f.experimental> - - Current status: uncertain – Currently we feel this feature cannot move out of experimental status. - - - <@f.overview> -

- var works exactly like val, except the local variable is not marked as final. -

- The type is still entirely derived from the mandatory initializer expression, and any further assignments, while now legal (because the variable is no longer final), aren't looked at to determine the appropriate type.
- For example, var x = "Hello"; x = Color.RED; does not work; the type of x will be inferred to be java.lang.String and thus, the x = Color.RED assignment will fail. If the type of x was inferred to be java.lang.Object this code would have compiled, but that's not howvar works. -

- - - <@f.confKeys> -
- lombok.var.flagUsage = [warning | error] (default: not set) -
- Lombok will flag any usage of var as a warning or error if configured. -
- - diff --git a/website/templates/features/index.html b/website/templates/features/index.html index 73b5dce8..d077ab4d 100644 --- a/website/templates/features/index.html +++ b/website/templates/features/index.html @@ -12,6 +12,10 @@ Finally! Hassle-free final local variables. + <@main.feature title="var" href="var"> + Mutably! Hassle-free local variables. + + <@main.feature title="@NonNull" href="NonNull"> or: How I learned to stop worrying and love the NullPointerException. diff --git a/website/templates/features/var.html b/website/templates/features/var.html new file mode 100644 index 00000000..60e24914 --- /dev/null +++ b/website/templates/features/var.html @@ -0,0 +1,27 @@ +<#import "_features.html" as f> + +<@f.scaffold title="var" logline="Mutably! Hassle-free local variables."> + <@f.history> +

+ + + <@f.overview> +

+ var works exactly like val, except the local variable is not marked as final. +

+ The type is still entirely derived from the mandatory initializer expression, and any further assignments, while now legal (because the variable is no longer final), aren't looked at to determine the appropriate type.
+ For example, var x = "Hello"; x = Color.RED; does not work; the type of x will be inferred to be java.lang.String and thus, the x = Color.RED assignment will fail. If the type of x was inferred to be java.lang.Object this code would have compiled, but that's not howvar works. +

+ + + <@f.confKeys> +
+ lombok.var.flagUsage = [warning | error] (default: not set) +
+ Lombok will flag any usage of var as a warning or error if configured. +
+ + -- cgit