Codecov Report

Merging #3857 into master will decrease coverage by 0.01%.
The diff coverage is 30.76%.

@@            Coverage Diff             @@
##           master    #3857      +/-   ##
==========================================
- Coverage   78.66%   78.64%   -0.02%     
==========================================
  Files         103      103              
  Lines      141899   141912      +13     
==========================================
- Hits       111618   111608      -10     
- Misses      30281    30304      +23

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4456ab5...9f8fe1e. Read the comment docs.

Yes, I also thought that scriptstrict should take an argument for the script version. And the version is used for checking version what Vim improved. And if the version is same as Vim's version, Vim compile the script to AST.
I don't worry about the '3' + 4 since the syntax tree is always fixed to (+ '3' 4) even if type of results are different for each them. Just return which one by + operator. The problem is that . operator have indeterminate meanings:

let a = "a"
let b = "b"
let c = "c"
let x = a.b.c

This mean:

(let = x (concat a b c))

But

let a = {"b": {"c"}}
let x = a.b.c

This mean:

(let = x (gethash 'c' (gethash 'b' a))

I don't see what's wrong with "." for string concatenation (still less why it would be "obsolete"). It seems to me that it's the dictionary notation that should be changed.

No. Vim script have dictionary function. And many plugins have the codes.

Vim script also has a string concatenation operator. And many plugins and scripts use it.

What do you worry about? I'm not trying to completely delete string concatings. If you want to use string concatings with "a.b", you can use if you don't put "scriptversion". This is only thing that scripts are not optimized in future.

I worry that no reason has been given for taking "." away from string concatenation (in "strict mode") instead of taking "." away from dictionary expressions. Why not just require (in "strict mode") the dictionary expression a.b to instead be a[b]?

@chdiza Dictionary expressions have always been written as a.b, so by changing that, all code has to be adapted. Whereas with string concatenation, the variant with whitespace around . has been used more often (at least that's my gut feeling) than the variant without, and (you might have missed that, as it's easy to overlook), the suggestion here is to only remove the latter variant. Code that uses a . b (or the inconsistent a .b) for concatenating could remain as-is. Also, the necessary change would be to just add missing whitespace, not changing the syntax altogether, like in your counter-proposal.

I concur with Bram that such endeavor should be part of a larger redesign. If this is done piecemeal through many minor revisions, and without discernible (performance) benefits, I doubt this will get much traction. Why should a plugin writer make changes that break backwards compatibility if there's a chance this soon needs to be adapted again?

Also, this probably won't silence those critics that dislike Vimscript in general (unless this gets a complete, radical overhaul, and then shouldn't be called Vimscript any longer). I wonder if we couldn't just leverage any performance optimizations from other scripting languages: If, say, Python does a great job there already, why not just invest some time in better and efficient Vim bindings, and then tell plugin writers to implement large plugins in Python?

Dictionary expressions have always been written as a.b

Haven't they also always been written as a[b]? Haven't string concats always been writable as a.b?

Dictionary expression certainly can be written a[b] (whether or not it was always thus), and often is so written; so it just isn't true that all dictionary code would have to be changed.

@chdiza In a.b, b is a a literal key (this works only for keys that consist entirely of letters, digits and underscore, as per :help E713). If you use a[b], b is a Vimscript expression (variable). To be equivalent, it would have to be written as a['b'] or a["b"].

Thus it's best if Vim does something that users expect from other languages.

Vim will need to keep "a[b]" anyway, because otherwise there's no way to distinguish between "a.b" where a is a dictionary and "b" is one of its string keys, and "a.b" where a is a dictionary and b is a variable whose value is one of a's keys.

let a = {"b" : 1, "c": 2, "foo": 3}
let b = "foo"
echo a.b

That will produce 1, so to get 3 via the variable b one will need to do echo a[b]. The latter is allegedly not in line with the expectations of users of (certain) other languages. So the battle to stay in line with those expectations was lost long ago.

As mentioned in above, Vim script have dictionary function.

let a = {"value": 1}
function! a.b(k)
  echo self[a:k]
endfunction

call a.b("value")

Many Vim plugins are using this idiom.

ex: https://github.com/vim-jp/vital.vim

And many script author is using spaces arround . for concat strings habitually to avoid consufing.

I want to suggest one more thing to be avoided confusing.

function! s:test()
  let l:l = 1
  let l:k = 2
  let l:c = [1,2,3]
  echo l:c[l:l:k]
endfunction

call s:test()

This is parsed as:

echo l:c[l:l: k]

But can be confused to:

echo l:c[l :l:k]

In strict mode, spaces arround : must be included.

echo l:c[l:l : k]

Any reason to leave out a. b for string concatenation? This is what I use most often, rather than a . b. I've never seen anybody using a .b (maybe I should look at more code ...). Reserving a.b for dict access should be fine. Adding another operator .. for string concatenation should be fine also (then whitespace wouldn't matter).

We don't mean that we will remove a.b for string concatenation. Just small thing that will not be optimized.

l:c[l:l:k] is confusing to but it's not a true ambiguity in the grammar, in the sense that the parsing does not depend on the type of the variables. I would think l:c[l:(l:k)] could be allowed.

@Houl is just saying to allow a. b under "strict," so a space on either side is allowable and means string concatenation.

By the way, can such a directive (or a different name) have the effect of:

let s:save_cpo = &cpo
set cpo&vim
...
let &cpo = s:save_cpo