[vim/vim] Use :var for object and class variable declarations (PR #13670)

dkearns

unread,

Dec 12, 2023, 7:23:43 AM12/12/23

to vim/vim, Subscribed

This PR modifies the object and class variable declarations to require use of the :var keyword.

The current object/class variable declaration syntax is inconsistent with that used in other language contexts where :var, :const, or :final introduce variables. It is also inconsistent with object/class method declarations which reuse the syntax employed for all other function declarations, i.e., :def.

Classes and interfaces are not special enough, as syntactic structures, to warrant these deviations. Similar programming languages usually reuse their general variable declaration syntax for field declarations, and the small number that don't use a dedicated and internally consistent class syntax.

Aside, from being a needless deviation from the general syntax with no obvious benefit, it also introduces various syntactic oddities, as highlighted by the proposed syntax for final object/class variables.

I initially raised this topic in and around the first call for comments on Vim9 classes, as did others. The last I heard was that it was still "under consideration" but, with the recent unfortunate developments, some of these decisions appear to have been implicitly crystallised without further discussion. As I dislike the syntax as much now, having actually used it anger, as I did when I first saw it twelve months ago it seems worth raising again while there is still an opportunity to change it.

For reference this topic is covered in vim9class.txt under "Rationale" -> "Declaring object and class variables".

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/13670

Commit Summary

2b290f0 Use :var for object and class variable declarations

File Changes

(7 files)

M runtime/doc/vim9class.txt (82)
M src/errors.h (8)
M src/testdir/test_vim9_builtin.vim (2)
M src/testdir/test_vim9_class.vim (967)
M src/testdir/test_vim9_disassemble.vim (16)
M src/testdir/test_vim9_typealias.vim (4)
M src/vim9class.c (72)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Dec 12, 2023, 9:39:04 AM12/12/23

to vim/vim, Subscribed

@yegappan requested changes on this pull request.

In runtime/doc/vim9class.txt:

> @@ -156,8 +156,8 @@ On the other hand, if you do not want the object variables to be read directly
 from outside the class or its sub-classes, you can make them protected.  This
 is done by prefixing an underscore to the name: >
 
-	this._lnum: number
-	this._col number
+	var_lnum: number
+	var_col number

A space is needed between var and "_lnum" and "_col".

In src/errors.h:

> @@ -3567,6 +3565,8 @@ EXTERN char e_using_class_as_var_val[]
 	INIT(= N_("E1405: Cannot use a Class as a variable or value"));
 EXTERN char e_using_typealias_as_var_val[]
 	INIT(= N_("E1406: Cannot use a Typealias as a variable or value"));
+EXTERN char e_static_must_be_followed_by_var_or_def[]
+	INIT(= N_("E1407: Static must be followed by \"var\" or \"def\""));

Can you reuse E1368 instead of introducing a new error number?

In src/testdir/test_vim9_class.vim:

> @@ -74,7 +74,7 @@ def Test_class_basic()
       this
     endclass
   END
-  v9.CheckSourceFailure(lines, 'E1317: Invalid object variable declaration: this', 3)
+  v9.CheckSourceFailure(lines, 'E1318: Not a valid command in a class: this', 3)

Can you add a test for using the prefix "variable" instead of "var" for the declaring an object variable?

In src/testdir/test_vim9_class.vim:

>  
   # Use "that" instead of "this"
   lines =<< trim END
     vim9script
     class Something
-      this.count: number
+      var count: number

Can you add a test for using the previous syntax using the "this" prefix with object and class variables and check whether they all fail?

In runtime/doc/vim9class.txt:

> @@ -690,8 +690,8 @@ value for the object variables will be used.  This is a more useful example,
 with default values: >
 
 	class TextPosition
-	   this.lnum: number = 1
-	   this.col: number = 1
+	   var lnum: number = 1
+	   var col: number = 1
 	endclass
 
 If you want the constructor to have mandatory arguments, you need to write it

The "Declaring object and class variables" section needs to be updated to reflect the rationale for using the "var" prefix now.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Dec 12, 2023, 9:40:12 AM12/12/23

to vim/vim, Subscribed

I like the rationale for making the variable declaration consistent inside and outside a class.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 12, 2023, 9:45:40 AM12/12/23

to vim/vim, Subscribed

I agree. I think consistently requiring the use of :var makes sense

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 13, 2023, 10:01:38 AM12/13/23

to vim/vim, Subscribed

@dkearns commented on this pull request.

In runtime/doc/vim9class.txt:

> @@ -156,8 +156,8 @@ On the other hand, if you do not want the object variables to be read directly
 from outside the class or its sub-classes, you can make them protected.  This
 is done by prefixing an underscore to the name: >
 
-	this._lnum: number
-	this._col number
+	var_lnum: number
+	var_col number

Done

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 13, 2023, 10:01:51 AM12/13/23

to vim/vim, Subscribed

@dkearns commented on this pull request.

In src/errors.h:

> @@ -3567,6 +3565,8 @@ EXTERN char e_using_class_as_var_val[]
 	INIT(= N_("E1405: Cannot use a Class as a variable or value"));
 EXTERN char e_using_typealias_as_var_val[]
 	INIT(= N_("E1406: Cannot use a Typealias as a variable or value"));
+EXTERN char e_static_must_be_followed_by_var_or_def[]
+	INIT(= N_("E1407: Static must be followed by \"var\" or \"def\""));

Done

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 13, 2023, 10:01:54 AM12/13/23

to vim/vim, Subscribed

@dkearns commented on this pull request.

In src/testdir/test_vim9_class.vim:

>  
   # Use "that" instead of "this"
   lines =<< trim END
     vim9script
     class Something
-      this.count: number
+      var count: number

Done

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 13, 2023, 10:01:57 AM12/13/23

to vim/vim, Subscribed

@dkearns commented on this pull request.

In runtime/doc/vim9class.txt:

> @@ -690,8 +690,8 @@ value for the object variables will be used.  This is a more useful example,
 with default values: >
 
 	class TextPosition
-	   this.lnum: number = 1
-	   this.col: number = 1
+	   var lnum: number = 1
+	   var col: number = 1
 	endclass
 
 If you want the constructor to have mandatory arguments, you need to write it

Done

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 13, 2023, 10:27:18 AM12/13/23

to vim/vim, Subscribed

great! thank you very muuuuuuuuuuch:
seems you are fixing another it was an odd case: this. 😄
// (#11827 (comment))

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Dec 13, 2023, 11:14:27 PM12/13/23

to vim/vim, Subscribed

@yegappan approved this pull request.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 14, 2023, 2:26:10 PM12/14/23

to vim/vim, Subscribed

thanks for this!

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 14, 2023, 2:29:00 PM12/14/23

to vim/vim, Subscribed

Closed #13670 via 74da0ee.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 14, 2023, 11:25:54 PM12/14/23

to vim/vim, Subscribed

vim9cmd var x = 123
in cmdline seems still cannot use 'var', is it designed, or forgot?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 15, 2023, 12:00:57 AM12/15/23

to vim/vim, Subscribed

There's a test for that usage, in a script, in test_vim9_cmd.vim where it's allowed but it's intentionally disallowed when called interactively, with a dedicated error message.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 15, 2023, 12:12:45 AM12/15/23

to vim/vim, Subscribed

yea, so do you know what's the reason why it was disallowed?
i felt it much useful if adhoc to run something..

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 15, 2023, 8:33:23 AM12/15/23

to vim/vim, Subscribed

Well, in Vim9 script var declared variables, outside of functions, are script local. So

vim9cmd var x = 123

doesn't make much sense on the command-line where x would be global. You can declare a global variable using

vim9cmd g:x = 123

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 15, 2023, 8:36:53 AM12/15/23

to vim/vim, Subscribed

@Shane-XB-Qian, it looks like you've been here before. 😄

#9881

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 15, 2023, 9:07:36 AM12/15/23

to vim/vim, Subscribed

> @Shane-XB-Qian, it looks like you've been here before. :smile:

:shrug: um... probably i may felt if scope was a matter, then why 'vim9cmd var t:x = 123' was not allowed?
i meant if `vim9cmd x = 123` err, but `vim9cmd t:x = 123` ok, then `vim9cmd var t:x = 123` should be ok too?
a.k.a here the latter one the 'var' keyword should be optional, if err, then err should be err about scope.
// BTW: var t:x = 123 also is disallowed in script (vs cmdline), i may recommend that 'var' keyword should be optional too.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 15, 2023, 9:18:07 AM12/15/23

to vim/vim, Subscribed

oh, one reason i can image perhaps because : to vim9, if 'var t:x' then x would a be type name.
if such, then let it be, how do you think?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 15, 2023, 9:25:34 AM12/15/23

to vim/vim, Subscribed

but here it is 't:x' not 't: x', so i have no idea why..

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 15, 2023, 9:29:41 AM12/15/23

to vim/vim, Subscribed

let's just leave it as it currently is.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 15, 2023, 9:58:22 AM12/15/23

to vim/vim, Subscribed

I thought it was a bit weird when I first saw it as well. If you think of them more as explicit global dictionaries, as they're presented via get(), it's easier to understand.

We could disallow type inference for these but then you have optional var (as the current mechanism has to be supported) and disallowed type inference.

Even if it was going to be supported it could be done in the future without any compatibility concerns.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 15, 2023, 10:08:08 AM12/15/23

to vim/vim, Subscribed

> I thought it was a bit weird when I first saw it as well. If you think of them more as explicit global dictionaries, as they're presented via `get()`, it's easier to understand.
> We could disallow type inference for these but then you have optional `var` (as the current mechanism has to be supported) _and_ disallowed type inference.

> Even if it was going to be supported it could be done in the future without any compatibility concerns.

ok, for this one, let's keep it as currently is for now,
// i may felt the 'var' should be optional, since the assignment is clear standed there,
// the err should be not about 'var'

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dkearns

unread,

Dec 15, 2023, 10:24:07 AM12/15/23

to vim/vim, Subscribed

Yes, the error is confusing. Is "E1079: Cannot declare a script-local variable on the command line" good enough?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 15, 2023, 10:35:40 AM12/15/23

to vim/vim, Subscribed

> Yes, the error is confusing. Is "E1079: Cannot declare a script-local variable on the command line" good enough?

1, yes, i think so, "E1079: Cannot declare a vim9 script-local variable on the command line", named it with 'vim9' then better.

2, but 'var t:x = 123' is not allowed in script also, so another point perhaps should be making 'var' is an optional in this case.
// this one perhaps can be planed in the future.

--
shane.xb.qian