patch 8.2.1744: Vim9: using ":const!" is weird
Problem: Vim9: using ":const!" is weird.
Solution: Use "var" - "final" - "const" like Dart. "let" still works for
now.
diff --git a/runtime/doc/vim9.txt b/runtime/doc/vim9.txt
index 576479b..4e5d2f3 100644
--- a/runtime/doc/vim9.txt
+++ b/runtime/doc/vim9.txt
@@ -1,4 +1,4 @@
-*vim9.txt* For Vim version 8.2. Last change: 2020 Sep 17
+*vim9.txt* For Vim version 8.2. Last change: 2020 Sep 26
VIM REFERENCE MANUAL by Bram Moolenaar
@@ -70,7 +70,7 @@
In legacy Vim script comments start with double quote. In Vim9 script
comments start with #. >
# declarations
- let count = 0 # number of occurrences
+ var count = 0 # number of occurrences
The reason is that a double quote can also be the start of a string. In many
places, especially halfway through an expression with a line break, it's hard
@@ -154,31 +154,32 @@
and cannot be deleted or replaced.
-Variable declarations with :let and :const ~
+Variable declarations with :var, :final and :const ~
*vim9-declaration*
-Local variables need to be declared with `:let`. Local constants need to be
-declared with `:const`. We refer to both as "variables".
+Local variables need to be declared with `:var`. Local constants need to be
+declared with `:final` or `:const`. We refer to both as "variables" in this
+section.
Variables can be local to a script, function or code block: >
vim9script
- let script_var = 123
+ var script_var = 123
def SomeFunc()
- let func_var = script_var
+ var func_var = script_var
if cond
- let block_var = func_var
+ var block_var = func_var
...
The variables are only visible in the block where they are defined and nested
blocks. Once the block ends the variable is no longer accessible: >
if cond
- let inner = 5
+ var inner = 5
else
- let inner = 0
+ var inner = 0
endif
echo inner # Error!
The declaration must be done earlier: >
- let inner: number
+ var inner: number
if cond
inner = 5
else
@@ -186,10 +187,10 @@
endif
echo inner
-To intentionally avoid a variable being available later, a block can be used:
->
+To intentionally hide a variable from code that follows, a block can be
+used: >
{
- let temp = 'temp'
+ var temp = 'temp'
...
}
echo temp # Error!
@@ -197,9 +198,9 @@
Declaring a variable with a type but without an initializer will initialize to
zero, false or empty.
-An existing variable cannot be assigned to with `:let`, since that implies a
-declaration. Global, window, tab, buffer and Vim variables can only be used
-without `:let`, because they are not really declared, they can also be deleted
+In Vim9 script `:let` cannot be used. An existing variable is assigned to
+without any command. The same for global, window, tab, buffer and Vim
+variables, because they are not really declared. They can also be deleted
with `:unlet`.
Variables and functions cannot shadow previously defined or imported variables
@@ -209,51 +210,50 @@
Global variables and user defined functions must be prefixed with "g:", also
at the script level. >
vim9script
- let script_local = 'text'
+ var script_local = 'text'
g:global = 'value'
- let Funcref = g:ThatFunction
+ var Funcref = g:ThatFunction
-Since "&opt = value" is now assigning a value to option "opt", ":&" cannot be
+Since `&opt = value` is now assigning a value to option "opt", ":&" cannot be
used to repeat a `:substitute` command.
- *vim9-const*
-In legacy Vim script "const list = []" would make the variable "list"
-immutable and also the value. Thus you cannot add items to the list. This
-differs from what many languages do. Vim9 script does it like TypeScript: only
-"list" is immutable, the value can be changed.
-One can use `:const!` to make both the variable and the value immutable. Use
+
+Constants ~
+ *vim9-const* *vim9-final*
+How constants work varies between languages. Some consider a variable that
+can't be assigned another value a constant. JavaScript is an example. Others
+also make the value immutable, thus when a constant uses a list, the list
+cannot be changed. In Vim9 we can use both.
+
+`:const` is used for making both the variable and the value a constant. Use
this for composite structures that you want to make sure will not be modified.
+Example: >
+ const myList = [1, 2]
+ myList = [3, 4] # Error!
+ myList[0] = 9 # Error!
+ muList->add(3) # Error!
-How this works: >
- vim9script
- const list = [1, 2]
- list = [3, 4] # Error!
- list[0] = 2 # OK
+`:final` is used for making only the variable a constant, the value can be
+changed. This is well known from Java. Example: >
+ final myList = [1, 2]
+ myList = [3, 4] # Error!
+ myList[0] = 9 # OK
+ muList->add(3) # OK
- const! LIST = [1, 2]
- LIST = [3, 4] # Error!
- LIST[0] = 2 # Error!
It is common to write constants as ALL_CAPS, but you don't have to.
The constant only applies to the value itself, not what it refers to. >
- cont females = ["Mary"]
- const! NAMES = [["John", "Peter"], females]
+ final females = ["Mary"]
+ const NAMES = [["John", "Peter"], females]
NAMES[0] = ["Jack"] # Error!
- NAMES[0][0] = ["Jack"] # Error!
+ NAMES[0][0] = "Jack" # Error!
NAMES[1] = ["Emma"] # Error!
Names[1][0] = "Emma" # OK, now females[0] == "Emma"
-Rationale: TypeScript has no way to make the value immutable. One can use
-immutable types, but that quickly gets complicated for nested values. And
-with a type cast the value can be made mutable again, which means there is no
-guarantee the value won't change. Vim supports immutable values, in legacy
-script this was done with `:lockvar`. But that is an extra statement and also
-applies to nested values. Therefore the solution to use `:const!`.
-
- *E1092*
+< *E1092*
Declaring more than one variable at a time, using the unpack notation, is
currently not supported: >
- let [v1, v2] = GetValues() # Error!
+ var [v1, v2] = GetValues() # Error!
That is because the type needs to be inferred from the list item type, which
isn't that easy.
@@ -296,7 +296,7 @@
without `function()`. The argument types and return type will then be checked.
The function must already have been defined. >
- let Funcref = MyFunction
+ var Funcref = MyFunction
When using `function()` the resulting type is "func", a function with any
number of arguments and any return type. The function can be defined later.
@@ -307,53 +307,53 @@
In many cases it is obvious that an expression continues on the next line. In
those cases there is no need to prefix the line with a backslash
|line-continuation|. For example, when a list spans multiple lines: >
- let mylist = [
+ var mylist = [
'one',
'two',
]
And when a dict spans multiple lines: >
- let mydict = #{
+ var mydict = #{
one: 1,
two: 2,
}
Function call: >
- let result = Func(
+ var result = Func(
arg1,
arg2
)
For binary operators in expressions not in [], {} or () a line break is
possible just before or after the operator. For example: >
- let text = lead
+ var text = lead
.. middle
.. end
- let total = start +
+ var total = start +
end -
correction
- let result = positive
+ var result = positive
? PosFunc(arg)
: NegFunc(arg)
For a method call using "->" and a member using a dot, a line break is allowed
before it: >
- let result = GetBuilder()
+ var result = GetBuilder()
->BuilderSetWidth(333)
->BuilderSetHeight(777)
->BuilderBuild()
- let result = MyDict
+ var result = MyDict
.member
< *E1050*
To make it possible for the operator at the start of the line to be
recognized, it is required to put a colon before a range. This will add
"start" and print: >
- let result = start
+ var result = start
+ print
Like this: >
- let result = start + print
+ var result = start + print
This will assign "start" and print a line: >
- let result = start
+ var result = start
:+ print
It is also possible to split a function header over multiple lines, in between
@@ -411,15 +411,15 @@
White space ~
Vim9 script enforces proper use of white space. This is no longer allowed: >
- let var=234 # Error!
- let var= 234 # Error!
- let var =234 # Error!
+ var name=234 # Error!
+ var name= 234 # Error!
+ var name =234 # Error!
There must be white space before and after the "=": >
- let var = 234 # OK
+ var name = 234 # OK
White space must also be put before the # that starts a comment after a
command: >
- let var = 234# Error!
- let var = 234 # OK
+ var name = 234# Error!
+ var name = 234 # OK
White space is required around most operators.
@@ -440,7 +440,7 @@
Conditions and expressions are mostly working like they do in JavaScript. A
difference is made where JavaScript does not work like most people expect.
-Specifically, an empty list is falsey.
+Specifically, an empty list is falsy.
Any type of variable can be used as a condition, there is no error, not even
for using a list or job. This is very much like JavaScript, but there are a
@@ -582,9 +582,10 @@
It is possible to nest `:def` inside another `:def` or
`:function` up to about 50 levels deep.
- [!] is used as with `:function`. Note that in Vim9
- script script-local functions cannot be deleted or
- redefined later in the same script.
+ [!] is used as with `:function`. Note that
+ script-local functions cannot be deleted or redefined
+ later in Vim9 script. They can only be removed by
+ reloading the same script.
*:enddef*
:enddef End of a function defined with `:def`. It should be on
@@ -612,14 +613,14 @@
Local variables will not be visible to string evaluation. For example: >
def EvalString(): list<string>
- let list = ['aa', 'bb', 'cc', 'dd']
+ var list = ['aa', 'bb', 'cc', 'dd']
return range(1, 2)->map('list[v:val]')
enddef
The map argument is a string expression, which is evaluated without the
function scope. Instead, use a lambda: >
def EvalString(): list<string>
- let list = ['aa', 'bb', 'cc', 'dd']
+ var list = ['aa', 'bb', 'cc', 'dd']
return range(1, 2)->map({ _, v -> list[v] })
enddef
@@ -690,23 +691,23 @@
And classes and interfaces can be used as types: >
:class MyClass
- :let mine: MyClass
+ :var mine: MyClass
:interface MyInterface
- :let mine: MyInterface
+ :var mine: MyInterface
:class MyTemplate<Targ>
- :let mine: MyTemplate<number>
- :let mine: MyTemplate<string>
+ :var mine: MyTemplate<number>
+ :var mine: MyTemplate<string>
:class MyInterface<Targ>
- :let mine: MyInterface<number>
- :let mine: MyInterface<string>
+ :var mine: MyInterface<number>
+ :var mine: MyInterface<string>
{not implemented yet}
-Variable types and type casting *variable-types*
-
+Variable types and type casting ~
+ *variable-types*
Variables declared in Vim9 script or in a `:def` function have a type, either
specified explicitly or inferred from the initialization.
@@ -716,10 +717,10 @@
This can be a problem when the "any" type is undesired and the actual type is
expected to always be the same. For example, when declaring a list: >
- let l: list<number> = [1, g:two]
+ var l: list<number> = [1, g:two]
This will give an error, because "g:two" has type "any". To avoid this, use a
type cast: >
- let l: list<number> = [1, <number>g:two]
+ var l: list<number> = [1, <number>g:two]
< *type-casting*
The compiled code will then check that "g:two" is a number at runtime and give
an error if it isn't. This is called type casting.
@@ -734,12 +735,12 @@
string to a number.
-Type inference *type-inference*
-
+Type inference ~
+ *type-inference*
In general: Whenever the type is clear it can be omitted. For example, when
declaring a variable and giving it a value: >
- let var = 0 # infers number type
- let var = 'hello' # infers string type
+ var name = 0 # infers number type
+ var name = 'hello' # infers string type
The type of a list and dictionary comes from the common type of the values.
If the values all have the same type, that type is used for the list or
@@ -749,8 +750,8 @@
[1, 'x', 3] list<any>
-Stricter type checking *type-checking*
-
+Stricter type checking ~
+ *type-checking*
In legacy Vim script, where a number was expected, a string would be
automatically converted to a number. This was convenient for an actual number
such as "123", but leads to unexpected problems (but no error message) if the
@@ -766,7 +767,7 @@
==============================================================================
-5. Namespace, Import and Export
+5. Namespace, Import and Export
*vim9script* *vim9-export* *vim9-import*
THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE
@@ -786,7 +787,7 @@
script in its own namespace, instead of the global namespace. If a file
starts with: >
vim9script
- let myvar = 'yes'
+ var myvar = 'yes'
Then "myvar" will only exist in this file. While without `vim9script` it would
be available as `g:myvar` from any other script and function.
@@ -809,7 +810,9 @@
*:export* *:exp*
Exporting an item can be written as: >
export const EXPORTED_CONST = 1234
- export let someValue = ...
+ export var someValue = ...
+ export final someValue = ...
+ export const someValue = ...
export def MyFunc() ...
export class MyClass ...
@@ -880,7 +883,7 @@
vim9script
import FilterFunc from "../import/someother.vim"
def searchfor#Stuff(arg: string)
- let filtered = FilterFunc(arg)
+ var filtered = FilterFunc(arg)
...
< This goes in .../autoload/searchfor.vim. "searchfor" in the file name
must be exactly the same as the prefix for the function name, that is how
@@ -889,7 +892,7 @@
3. Other functionality, possibly shared between plugins, contains the exported
items and any private items. >
vim9script
- let localVar = 'local'
+ var localVar = 'local'
export def FilterFunc(arg: string): string
...
< This goes in .../import/someother.vim.
@@ -909,7 +912,7 @@
6. Future work: classes *vim9-classes*
Above "class" was mentioned a few times, but it has not been implemented yet.
-Most of Vim9 script can be created without this funcionality, and since
+Most of Vim9 script can be created without this functionality, and since
implementing classes is going to be a lot of work, it is left for the future.
For now we'll just make sure classes can be added later.
@@ -941,7 +944,7 @@
The :def command ~
-Plugin writers have asked for a much faster Vim script. Investigations have
+Plugin writers have asked for much faster Vim script. Investigations have
shown that keeping the existing semantics of function calls make this close to
impossible, because of the overhead involved with calling a function, setting
up the local function scope and executing lines. There are many details that
@@ -952,7 +955,7 @@
Therefore the `:def` method to define a new-style function had to be added,
which allows for a function with different semantics. Most things still work
as before, but some parts do not. A new way to define a function was
-considered the best way to separate the old-style code from Vim9 script code.
+considered the best way to separate the legacy style code from Vim9 style code.
Using "def" to define a function comes from Python. Other languages use
"function" which clashes with legacy Vim script.
@@ -968,12 +971,12 @@
of the arguments and decide what kind of addition to do. And when the
type is dictionary throw an error. If the types are known to be numbers then
an "add number" instruction can be used, which is faster. The error can be
-given at compile time, no error handling is needed at runtime, adding two
-numbers cannot fail.
+given at compile time, no error handling is needed at runtime, since adding
+two numbers cannot fail.
-The syntax for types is similar to Java, since it is easy to understand and
-widely used. The type names are what were used in Vim before, with some
-additions such as "void" and "bool".
+The syntax for types, using <type> for compound types, is similar to Java. It
+is easy to understand and widely used. The type names are what were used in
+Vim before, with some additions such as "void" and "bool".
Removing clutter and weirdness ~
@@ -981,10 +984,10 @@
Once decided that `:def` functions have different syntax than legacy functions,
we are free to add improvements to make the code more familiar for users who
know popular programming languages. In other words: remove weird things that
-only Vim uses.
+only Vim does.
We can also remove clutter, mainly things that were done to make Vim script
-backwards compatible with good old Vi commands.
+backwards compatible with the good old Vi commands.
Examples:
- Drop `:call` for calling a function and `:eval` for manipulating data.
@@ -993,44 +996,26 @@
However, this does require that some things need to change:
- Comments start with # instead of ", to avoid confusing them with strings.
+ This is good anyway, it is known from several popular languages.
- Ex command ranges need to be prefixed with a colon, to avoid confusion with
expressions (single quote can be a string or a mark, "/" can be divide or a
search command, etc.).
Goal is to limit the differences. A good criteria is that when the old syntax
-is used you are very likely to get an error message.
+is accidentally used you are very likely to get an error message.
-TypeScript syntax and semantics ~
+Syntax and semantics from popular languages ~
Script writers have complained that the Vim script syntax is unexpectedly
different from what they are used to. To reduce this complaint popular
languages are used as an example. At the same time, we do not want to abandon
the well-known parts of legacy Vim script.
-Since Vim already uses `:let` and `:const` and optional type checking is
-desirable, the JavaScript/TypeScript syntax fits best for variable
-declarations: >
- const greeting = 'hello' # string type is inferred
- let name: string
- ...
- name = 'John'
-
-Expression evaluation was already close to what JavaScript and other languages
-are doing. Some details are unexpected and can be fixed. For example how the
-|| and && operators work. Legacy Vim script: >
- let value = 44
- ...
- let result = value || 0 # result == 1
-
-Vim9 script works like JavaScript/TypeScript, keep the value: >
- let value = 44
- ...
- let result = value || 0 # result == 44
-
-Another reason why TypeScript can be used as an example for Vim9 script is the
+For many things TypeScript is followed. It's a recent language that is
+gaining popularity and has similarities with Vim script. It also has a
mix of static typing (a variable always has a known value type) and dynamic
-typing (a variable can have different types, this hanges at runtime). Since
+typing (a variable can have different types, this changes at runtime). Since
legacy Vim script is dynamically typed and a lot of existing functionality
(esp. builtin functions) depends on that, while static typing allows for much
faster execution, we need to have this mix in Vim9 script.
@@ -1054,7 +1039,7 @@
- TypeScript can use an expression like "99 || 'yes'" in a condition, but
cannot assign the value to a boolean. That is inconsistent and can be
annoying. Vim recognizes an expression with && or || and allows using the
- result as a bool.
+ result as a bool. TODO: to be reconsidered
- TypeScript considers an empty string as Falsy, but an empty list or dict as
Truthy. That is inconsistent. In Vim an empty list and dict are also
Falsy.
@@ -1063,6 +1048,80 @@
which is more flexible, but is only checked at runtime.
+Declarations ~
+
+Legacy Vim script uses `:let` for every assignment, while in Vim9 declarations
+are used. That is different, thus it's good to use a different command:
+`:var`. This is used in many languages. The semantics might be slightly
+different, but it's easily recognized as a declaration.
+
+Using `:const` for constants is common, but the semantics vary. Some
+languages only make the variable immutable, others also make the value
+immutable. Since "final" is well known from Java for only making the variable
+immutable we decided to use that. And then `:const` can be used for making
+both immutable. This was also used in legacy Vim script and the meaning is
+almost the same.
+
+What we end up with is very similar to Dart: >
+ :var name # mutable variable and value
+ :final name # immutable variable, mutable value
+ :const name # immutable variable and value
+
+Since legacy and Vim9 script will be mixed and global variables will be
+shared, optional type checking is desirable. Also, type inference will avoid
+the need for specifying the type in many cases. The TypeScript syntax fits
+best for adding types to declarations: >
+ var name: string # string type is specified
+ ...
+ name = 'John'
+ const greeting = 'hello' # string type is inferred
+
+This is how we put types in a declaration: >
+ var mylist: list<string>
+ final mylist: list<string> = ['foo']
+ def Func(arg1: number, arg2: string): bool
+
+Two alternatives were considered:
+1. Put the type before the name, like Dart: >
+ var list<string> mylist
+ final list<string> mylist = ['foo']
+ def Func(number arg1, string arg2) bool
+2. Put the type after the variable name, but do not use a colon, like Go: >
+ var mylist list<string>
+ final mylist list<string> = ['foo']
+ def Func(arg1 number, arg2 string) bool
+
+The first is more familiar for anyone used to C or Java. The second one
+doesn't really has an advantage over the first, so let's discard the second.
+
+Since we use type inference the type can be left out when it can be inferred
+from the value. This means that after `var` we don't know if a type or a name
+follows. That makes parsing harder, not only for Vim but also for humans.
+Also, it will not be allowed to use a variable name that could be a type name,
+using `var string string` is too confusing.
+
+The chosen syntax, using a colon to separate the name from the type, adds
+punctuation, but it actually makes it easier to recognize the parts of a
+declaration.
+
+
+Expressions ~
+
+Expression evaluation was already close to what JavaScript and other languages
+are doing. Some details are unexpected and can be fixed. For example how the
+|| and && operators work. Legacy Vim script: >
+ var value = 44
+ ...
+ var result = value || 0 # result == 1
+
+Vim9 script works like JavaScript/TypeScript, keep the value: >
+ var value = 44
+ ...
+ var result = value || 0 # result == 44
+
+TODO: the semantics of || and && need to be reconsidered.
+
+
Import and Export ~
A problem of legacy Vim script is that by default all functions and variables
@@ -1122,7 +1181,7 @@
testing, the `:defcompile` command will help out.
-Why not use an embeded language? ~
+Why not use an embedded language? ~
Vim supports interfaces to Perl, Python, Lua, Tcl and a few others. But
these interfaces have never become widely used, for various reasons. When