[vim/vim] Script-scoped function arguments (Issue #12682)

Igbanam Ogbuluijah

unread,

Jul 17, 2023, 3:08:15 PM7/17/23

to vim/vim, Subscribed

Steps to reproduce

With

vim9script

def Padding(s: string)
  echom "  " .. s .. "  "
enddef

var s = "this" .. ":" .. "that"
s->Padding()

…as ./this.vim, run Vim with

vim --clean +'so ./this.vim'

Expected behaviour

this:that should be echoed as a message.

s as the function argument should be local to the function scope; i.e. equivalent to l:s in legacy Vimscript. Instead, seems the function argument is equivalent to s:s

Version of Vim

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 23 2023 15:15:13)

Environment

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 23 2023 15:15:13)
macOS version - arm64
Included patches: 1-1650

Mac OS X
iTerm
xterm-256color-italic
ZSH

Logs and stack traces

No response

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

bfrg

unread,

Jul 17, 2023, 8:18:05 PM7/17/23

to vim/vim, Subscribed

That's not a bug. When you source the above script, Vim throws the following error:

E1168: Argument already declared in the script: s

Under :h E1168 you can find the explanation.

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

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

Christian Brabandt

unread,

Jul 18, 2023, 2:12:03 AM7/18/23

to vim/vim, Subscribed

closing

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

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

Christian Brabandt

unread,

Jul 18, 2023, 2:12:04 AM7/18/23

to vim/vim, Subscribed

Closed #12682 as completed.

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

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

Igbanam Ogbuluijah

unread,

Jul 19, 2023, 1:13:42 PM7/19/23

to vim/vim, Subscribed

@bfrg what I was trying to point out is that these are two different scopes. As an argument to a function, the variable should be in local scope, but it's polluting the script scope.

Technically, we shouldn't be getting E1168 here

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

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

bfrg

unread,

Jul 19, 2023, 1:28:12 PM7/19/23

to vim/vim, Subscribed

IIRC this has been discussed somewhere but I don't remember where and what the reasons were for the current behavior. Feel free to reopen and mark this issue as a feature request.

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

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

Christian Brabandt

unread,

Jul 19, 2023, 2:43:53 PM7/19/23

to vim/vim, Subscribed

This was an intentional choice. I don't remember any discussions on this and the relevant commit does not mention an issue number or similar: 9a01511

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

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

Christian Brabandt

unread,

Jul 20, 2023, 1:40:22 AM7/20/23

to vim/vim, Subscribed

Actually there was a bit of discussion at the end of the commit: 9a01511

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

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

Lifepillar

unread,

Jul 20, 2023, 6:55:44 AM7/20/23

to vim/vim, Subscribed

Maybe, an example in :h E1168 would help clarify this design choice? Currently, the help tells the what, but not the why.

In the above mentioned discussion, the main motivation seems to be summarized by this sentence:

It has bitten me several times, especially in a long function, that I thought I was using an object member, but it was
shadowed by a function argument.

This sounds like a valid argument, but it took me a few minutes to come up with an example (and I am not sure that this is the best example):

class A
  this.x: number
endclass

const a = A.new()

def F(a: A)
  # Long body referring to a.x at some point
enddef

const a2 = A.new()
F(a2)

If I understand correctly, the problem E1168 avoids is that the user's intention may be to have a function using a script-level object a. For some reason (perhaps, after a refactoring that renames variables?), that function ends up having a parameter with the same name, at which point a in the body of the function does not refer to the script-level object any more.

I have encountered E1168 several times, and to me it was a mild annoyance, because the code did not have any unintentional shadowing. But the error forces you to use different names for different things within the same script, which one may argue is good for clarity or legibility. To me, this falls in the class of the “language features forcing some discipline on you” (similar to mandatory spacing).

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

Reply all

Reply to author

Forward